I'm not working full time on Qpid anymore but I have some thoughts on this
issue. I get back to you with more useful comments as
soon as I can make some time.
On Mon, Jun 8, 2020 at 4:11 PM Straub, Albert
wrote:
> Hello,
>
>
>
> My colleague has written partial integration of libwebsocket clien
Create an "enhancement request" issue at
https://issues.apache.org/jira/projects/PROTON/issues with as much detail
as possible - e.g. proposed API you'd like to see.
If you're feeling adventurous you can have a go at fixing it yourself (but
make an issue anyway as a place to discuss it with the te
On Thu, Feb 20, 2020 at 3:44 PM Rick van Rein wrote:
> Hey Alan,
>
> Thanks!
>
> This does sound like I'd be diving under the API and that could make my
> code fragile...
>
> But maybe a Qpid developer recognises it as a usecase and it'd have a
> safe API in the future.
>
Open a request at http:
On Thu, Feb 20, 2020 at 3:44 PM Rick van Rein wrote:
> Hey Alan,
>
> Thanks!
>
> This does sound like I'd be diving under the API and that could make my
> code fragile...
>
> But maybe a Qpid developer recognises it as a usecase and it'd have a
> safe API in the future.
>
>
> Best wishes,
> -R
On Thu, Feb 20, 2020 at 8:55 AM Rick van Rein wrote:
> Hello,
>
> If I understand correctly, then Containers can be connected to multiple
> peers, in any combination of sending and receiving. So I should be able
> to call Container.connect() as often as I need.
>
> 1. To avoid more connections t
On Mon, Jan 27, 2020 at 7:44 AM Justin Ross wrote:
> I like to think of the message as a pure value object. As a result, it can
> have whatever lifecycle the API user chooses. For me, that's a reason to
> isolate it from the delivery and tracker, because they do have more tightly
> defined life
Would sending the messages pre-settled solve this problem? That would allow
the router to drop them for other reasons (inter-router congestion) but I
always found the notion of wanting settlement of a multicast message to be
a bit strange (what if there's nobody, what if they give different
outcome
On Mon, Jun 17, 2019 at 3:33 AM Schaik, Jacco van
wrote:
> Hi,
>
> I'm building an application using the Qpid Proton C API, version 0.28.0.
> I'm using a Connection Driver because my application has its own event
> loop.?
>
> Everything seems to be working, but the application on the other side o
On Mon, Jun 17, 2019 at 3:33 AM Schaik, Jacco van
wrote:
> Hi,
>
> I'm building an application using the Qpid Proton C API, version 0.28.0.
> I'm using a Connection Driver because my application has its own event
> loop.?
>
> Everything seems to be working, but the application on the other side o
you're careful but I'd be worried about potential
for confusion with connection options over-writing each other in multiple
different places.
>
> Thanks,
> Ali
>
> From: Alan Conway
> Sent: jeudi 2 mai 2019 21:29
> To: users@qpid.apache.org
> Subject: Re: [P
::endl;
proton::connection_options co;
proton::reconnect_options ro;
ro.failover_urls({"badX","badY"});
co.reconnect(ro);
t.connection().reconnect_update(co); // Apply new options to
connection
}
if (n > 20) { exit(0); } //
and are available
in the current release 0.27. You should be able to take advantage of them
now.
> Regards,
> Ali
>
> -Original Message-
> From: Alan Conway
> Sent: jeudi 24 janvier 2019 23:24
> To: users@qpid.apache.org
> Subject: Re: [Proton-C] Discovery
>
>
Welcome Jiri!
On Mon, Mar 4, 2019 at 3:12 AM Keith W wrote:
> Indeed, welcome!
>
> On Sat, 2 Mar 2019 at 21:08, Jiri Daněk wrote:
> >
> > On Fri, Mar 1, 2019 at 11:12 AM Robbie Gemmell >
> > wrote:
> >
> > > The Qpid PMC have voted to grant commit rights to Jiri Danek in
> > > recognition of c
are syntactic differences - the callback is
on_transport_error(), and instead of returning URLs you update the
reconnect options - but the functionality is the same. Does that sound
right?
> Best regards,
> Rabih
>
>
> On Fri, Jan 18, 2019 at 4:58 PM Alan Conway wrote:
&g
On Fri, Jan 18, 2019 at 10:35 AM Alan Conway wrote:
>
>
> On Thu, Jan 17, 2019 at 6:56 AM Rabih M wrote:
>
>> Hello,
>>
>> What Olivier was proposing is more at the level of the C++ proton binding.
>> What we would like to do is:
>> Instead of taki
nsport_error(transport& t) {
t.connection().reconnect_options(connection::options().reconnect().failover_urls(pick_my_urls());
}
> We would like to know if it sounds reasonable to you before proposing a
> patch. WDYT?
>
> Best regards,
> Rabih
>
> On Thu, Jan 3, 2019 at 9:15 PM
On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim wrote:
> Are you talking specifically about something at the c level rather than
> e.g. c++?
>
> As far as I recall, the c layer has no built in support for
> reconnection, that is added by the c++ (or other) wrappers.
>
> In the c++ api, perhaps the reco
On Sat, Nov 3, 2018 at 6:32 PM Chuck Rolke wrote:
> Hi basavaraj,
>
> The issue here is that the broker wants to negotiate a SASL layer but the
> Proton C++ example is skipping that during connection startup. AMQP allows
> startup options SASL and TLS before jumping into an AMQP session. SASL
> p
Can you try your case with the latest source on the master branch? This may
be a symptom of a recently fixed bug:
PROTON-1953: [go] occasional client/server hang with high volume of messages
Although the bug was observed with many small messages, I think it could
also cause problems with large me
Many thanks for figuring this out, I'll add an example to the Go binding.
Both the Go and C++ examples are currently quite horrible - very raw access
to the somewhat nasty underlying AMQP definitions. I will look into
providing a more "cooked" API to simplify this task, along the lines of the
pyth
-0
Found a bug in the new c++ connect config feature regarding tls. Not a
blocker if it is the only problem but I'd like to fix if we respin
On Mon, Oct 1, 2018, 12:01 PM Timothy Bish, wrote:
> On 10/01/2018 09:58 AM, Robbie Gemmell wrote:
> > Hi folks,
> >
> > I have put together a spin for a
On Mon, Sep 24, 2018 at 4:36 PM Alan Conway wrote:
>
>
> On Mon, Sep 24, 2018 at 9:48 AM Chuck Rolke wrote:
>
>> This was discussed in https://issues.apache.org/jira/browse/QPID-7926
>>
>> I'm not sure how far the resolution made it into the upstream sourc
reproduce it?
I'll get on it ASAP.
Thanks,
Alan.
> Thanks
> Nathan
>
>
>
> From: Alan Conway [mailto:acon...@redhat.com]
> Sent: 07 September 2018 16:10
> To: users@qpid.apache.org[mailto:users@qpid.apache.org]
> Cc: n...@gmx.es[mailto:n...@gmx.es]
> Subject: R
On Mon, Sep 24, 2018 at 9:48 AM Chuck Rolke wrote:
> This was discussed in https://issues.apache.org/jira/browse/QPID-7926
>
> I'm not sure how far the resolution made it into the upstream source.
>
Looks like that never got merged, seems like an oversight.
> - Original Message -
> > F
On Thu, Sep 6, 2018 at 3:53 PM, Cliff Jansen wrote:
> Have you tried the libuv proactor implementation for Proton-C? See
> qpid-proton/c/CMakeLists.txt.
>
> The current release of libuv claims to be fully supported on "Linux >=
> 2.6.32 with glibc >= 2.12".
>
> If libuv works for you, that might
I think this is a bug I fixed recently, it should be in the latest release
proton-0.25. If you still have a problem please raise a JIRA.
Here's the fix - NULL is somewhat special but it is a valid scalar type, so
I added it to type_id_is_scalar()
https://github.com/alanconway/qpid-proton/commit/9
+1, works in the Envoy bridge
On Thu, Jun 28, 2018 at 1:14 PM, Ken Giusti wrote:
> +1
>
> Successfully pass both the qdrouterd smoke tests and oslo.messaging
> functional tests
>
>
> On Tue, Jun 26, 2018 at 10:56 AM, Robbie Gemmell >
> wrote:
>
> > Hi folks,
> >
> > I have put together a spin f
On Tue, Jun 19, 2018 at 1:16 PM, Gordon Sim wrote:
> On 19/06/18 17:56, Alan Conway wrote:
>
>> On Tue, Jun 19, 2018 at 11:55 AM, Gordon Sim wrote:
>>
>> On 19/06/18 16:44, Alan Conway wrote:
>>>
>>> A related (not identical) issue is
>>>&
On Tue, Jun 19, 2018 at 11:55 AM, Gordon Sim wrote:
> On 19/06/18 16:44, Alan Conway wrote:
>
>> A related (not identical) issue is
>> https://issues.apache.org/jira/browse/DISPATCH-244
>> Andrews fix will fix that problem as well as the failures discussed here.
>&
A related (not identical) issue is
https://issues.apache.org/jira/browse/DISPATCH-244
Andrews fix will fix that problem as well as the failures discussed here.
Installing config files will not, nor will it help with developers trying
out examples in a source build etc.
I agree that this is not an
On Fri, Jun 15, 2018 at 1:02 PM, Andrew Stitcher
wrote:
>
> > ...
> >
> > I think 'problematic' is the wrong term to use there (seems somewhat
> > libelous!).
>
I know I'm going into bike shedding territory here (!) but do you have
> another word that you think is less 'libelous'? IMO every word
On Thu, May 24, 2018 at 1:59 PM, Ganesh Murthy wrote:
> On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke wrote:
>
> > Releasing the messages sounds like the better choice.
> >
> > It also would be nice if the router could revoke the sender's credit so
> > that he could not send any more. This would
e
> Python Requests library doc uses this technique pretty effectively:
>
> http://docs.python-requests.org/en/latest/user/advanced/
>
> On Thu, May 3, 2018 at 4:18 PM, Alan Conway wrote:
>
> > On Wed, May 2, 2018 at 7:01 AM, Robbie Gemmell >
> > wrote:
> >
>
On Wed, May 2, 2018 at 7:01 AM, Robbie Gemmell
wrote:
> I'm not likely to be much use on that, but a link to or description or
> where the changes are might help for folks that can be.
>
Doh! https://alanconway.github.io/
> On 30 April 2018 at 21:24, Alan Conway wrote:
I've written some small bits of proton-C documentation on multi-threading
and buffering. I plan to include them in the next release and would
appreciate any feedback that might help improve them.
Thanks,
Alan.
Thanks. I expect we can get that sorted for next release.
On Thu, Apr 26, 2018 at 9:10 AM, Baptiste Robert wrote:
> Update:
>
> I opened a JIRA : https://issues.apache.org/jira/browse/PROTON-1833
>
>
> 2018-04-23 16:50 GMT+02:00 Alan Conway :
>
> > On Mon, Apr 23
On Mon, Apr 23, 2018 at 5:37 AM, Baptiste Robert wrote:
> Hello,
>
> I'm encountering a crash in the proton library. What I'm doing ? Just
> creating a proton::container, listening locally on 0.0.0.0:5672 and then
> call stop() on the container and getting outside of the scope (object is
> then d
On Mon, Apr 16, 2018 at 1:50 PM, Gordon Sim wrote:
> On 16/04/18 15:24, Ken Giusti wrote:
>
>> To reply to my own question:
>>
>> IMHO when sending an unsettled multicast I would expect
>> 1) that all present consumers will get a copy of the message and:
>> 2) that any potential consumers that ar
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.
> >>
> >> It's as if you applied a priority to each disposi
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
> ACCEPTED
> MODIFIED
> RELEASED
>
> The router returns the highest priority disposition from all
> consumer's retur
On Mon, Apr 16, 2018 at 9:10 AM, mlange wrote:
> aconway.rh wrote
> > On Mon, Apr 16, 2018 at 8:52 AM, Gordon Sim <
>
> > gsim@
>
> > > wrote:
> >
> >
> >>
> >> No. The problem is that a transaction could involve messages to/from
> >> different brokers, i.e. the transaction would become a distrib
On Mon, Apr 16, 2018 at 8:52 AM, Gordon Sim wrote:
> On 16/04/18 12:30, mlange wrote:
>
>> Hi all,
>>
>> QDR has some limited support for transactions, seeing a special endpoint
>> $coordinator.
>> When one has QDR with only one broker behind it you can do a
>>
>> linkRoute {
>>prefix: $coord
2018-04-06 9:22 GMT-04:00 Michiel Lange :
> Hi,
>
> I use Qpid Dispatch to route JMS to an Artemis broker, which I have
> configured to use LDAP; allowing certain groups to create queues, send
> messages or receive.
> I am strugging getting Qpid dispatch to even use authentication, leave
> alone i
s.apache.org/repos/asf?p=qpid-proton.git;a=tree;h=HEAD
>
> On Wed, Mar 14, 2018 at 5:40 AM, Alan Conway wrote:
>
> > On Mon, Mar 12, 2018 at 12:14 PM, Justin Ross
> > wrote:
> >
> > > > src/messenger still there - oversight, or do we need to hold onto
> this?
Sadly the 0.22 ruby library has a new feature Container#schedule that does
not work properly (scheduled code sometimes doesn't run) - it's very likely
users will run into this if they use the feature.
I have fixed this properly for 0.23 and there's a small monkey patch to
work around it on 0.22, s
+1
make && ctest on f27 with combinations including:
C/C++ compilers: gcc, clang
Proactors: libuv, epoll
Debug and Release builds
Bindings: cpp, go, ruby, python (tox python 2.7, 3.6)
All tests passed except for known timeout problem in C++ examples run under
valgrind.
This is not a release block
On Fri, Mar 23, 2018 at 9:10 AM, Robbie Gemmell
wrote:
> The C code isn't in my wheelhouse, but it sounds like a bug. Its
> probably just been expected it would start at 0 as it does elsewhere,
> but I dont see anything in the spec requiring that and it isnt
> negotiated.
>
> You can raise JIRAs
On Tue, Mar 20, 2018 at 9:07 AM, Oleksandr Rudyy wrote:
> I think that publishing/consuming transactions should not be
> committable after queue deletion.
>
To play devils advocate: the transaction is isolated (the I in ACID) and
queue deletion is outside the scope of the transaction.
Consider
are of a
fix already in the cmake files.Perhaps someone else on the list can answer
that.
> Thank you,
>
>
> 2018-03-19 15:21 GMT+01:00 Alan Conway :
>
> > On Mon, Mar 19, 2018 at 4:45 AM, Baptiste Robert <
> > baptisterober...@gmail.com
> > > wrote:
> &g
On Mon, Mar 19, 2018 at 4:45 AM, Baptiste Robert wrote:
> Hello,
>
> I'm having an issue with the broker example. When I run it works, but a
> soon as I send messages to it I get a segfault. I send messages with the
> examples simple_send.
>
> Note : I compiled the broker with gcc 4.6.2 e.g. with
In C++ you can convert a proton::value containing an AMQP map to/from
std::deque, std::vector, std::list, std::forward_list or std::deque of
std::pair That preserves order in decoding
and gives you control of the order for encoding.
You need to #include or whichever to enable the
conversion - ha
On Thu, Mar 15, 2018 at 9:28 AM, Baptiste Robert wrote:
> Hello everybody,
>
> I currently have an issue with the qpid-proton c++ implementation on
> windows. I can't connect to a Java broker with an authenticationproviders
> set to : PlainPasswordFile.
>
> I built the simple_send examples and I
On Mon, Mar 12, 2018 at 12:14 PM, Justin Ross wrote:
> > src/messenger still there - oversight, or do we need to hold onto this?
> >
>
> It's still used by one of the test tools.
>
>
We can replace msgr-send.c and msgr-recv.c by copying from
examples/c/[send.c, send-ssl.c, receive.c] and adding o
Overall it's good.
Things to consider - none are essential:
drop 'binding/', put the language bindings directly in the root dir. It's
pretty obvious what they are - ruby, go, cpp etc.
Possibility: a "c" or "core" subdir rather than having the core src/
directly in root - clarify that the c-core
; >> Whilst the recommendation is clearly not what is being used, how much
> >> of an issue is this? It doesnt seem to be a hard requirement for
> >> example.
> >>
> >> I wonder if the disruption caused from changing it after ~6 years and
> >> dealing w
The proton ruby gem and package are incorrectly named according to the
standard gem naming rules, see
https://issues.apache.org/jira/browse/PROTON-1760 for details.
The short story is we want to change the name from "qpid_proton" to
"qpid-proton" for the next release (0.22, not the 0.21 release in
+1
- verified checksums
- build and test (including go, ruby bindings)
- ran tests from PROTON-1766
- build/test dispatch master using installed proton 0.21
On Wed, Feb 28, 2018 at 3:36 PM, Ted Ross wrote:
> +1
> - Built and Installed on Fedora 27
> - Proton tests all pass
> - Built qpid-dis
I seem to remember at some point there was a bug in the reactor which
caused events to get stuck and repeated in on_stop. In that case it was
related to scheduled events but this sounds similar.
Very odd that it works differently on different platforms. Perhaps
differences in the behavior of select
On Fri, Feb 23, 2018 at 5:43 AM, Baptiste Robert wrote:
> Hi everybody,
>
> I'm struggling a little bit with the global architecture of proton cpp. I'm
> trying to code a wrapper to simplify the utilization for a end user.
> This wrapper is divided in two classes, a "client" that launch the
> pro
Possible you've found a bug, but also possible you're hitting some C++
template type-mismatch potholes. C++ compilers often give incomprehensible
error messages for such problems. Post a code snip that illustrates the
problem with the compiler version you're using, and the error message you
see.
I
On Tue, Feb 13, 2018 at 8:30 AM, Rabih M wrote:
> Hello,
>
> As Olivier said at Murex we wrote a small C++ client with an imperative API
> that wraps proton. At that time we did not know that the community had
> plans to develop one.
>
> The API we wrote was inspired from JMS (connection, session
Use the on_transport_closed event to detect a client closing it's TCP
connection. Other closed events (on_link_closed, on_connection_closed) are
generated when the remote end politely closes the AMQP state associated
with link, connection etc. - you will not get these events if there's a
failure an
Updated the go1 branch in the repo: `go get qpid.apache.org/...` and
https://godoc.org/qpid.apache.org are now at tag 0.19.0
On Wed, Jan 3, 2018 at 2:01 PM, Ken Giusti wrote:
> I've just built and uploaded the python bindings for 0.19.0 to Pypi:
>
> https://pypi.python.org/pypi/python-qpid-proto
A note on the C++ API: std::string or `const char*` will be encoded as an
AMQP String (unicode), to encode as AMQP binary use the proton::binary type
(which is just a std::vector) .
When decoding, you can say e.g. proton::get(msg.body()) which
will throws unless the body type is exactly AMQP stri
+1
fedora27, self tests, manual check of ruby and go examples.
On Thu, Dec 21, 2017 at 10:18 AM, Chuck Rolke wrote:
> +1
>
> on Fedora 27
> * Verified checksum
> * ran selftests [1]
> * linked with qpid-dispatch master
> * ran qpid-dispath selftests
>
> [1] On first go self qpid-proton test fai
roblem for
error handling in servers, as failure to listen is not reported properly to
the app and could be missed leaving a hung server.
Proton 1724 is a trivial example fix, not worth respin on its own but worth
including if we do respin for 1724.
On Wed, Dec 20, 2017 at 9:03 AM, Alan Conway wrot
-0.5
I found a problem with error handling in ruby, it causes misbehavior
(silent exit or unexpected exception depending on how the app is written)
in the fairly common case of listening on a port that is already taken.
All other tests I did looked fine: build, install, self-test, build and
self-
I'm not aware of any plans to work on Python 3 support for qpid-python,
although it's possible somebody else has an interest in it. If you are
interested in working on it yourself, open a JIRA and attach patches, we
can get them applied to a future release.
On Thu, Dec 14, 2017 at 5:11 AM, andi we
tively you can set up a GOPATH with multiple entries, one pointing
to the proton-c/bindings/go subdirectory in a complete checkout of the
master branch.
On Thu, Dec 14, 2017 at 11:55 AM, Alessio Gottardo
wrote:
>
>
> On Thursday, 9 November 2017, 20:17:41 GMT, Alan Conway <
>
Hi Andreas,
Dispatch router has an optional HTTP console component that is built using
libwebsockets, it looks like you have an older libwebsockets that is
missing some features dispatch needs.
You should be able to build (without HTTP console support) by saying `cmake
-DUSE_LIBWEBSOCKETS=NO`
Ca
Proton will raise a proton::error, which just inherits
std::runtime_exception. The e.what() message should include the "name:
descripition" from the AMQP condition that was received on the wire.
If you are closing a connection at your end and want to send a message to
the other end you can call co
Have you tried turning the timeout off completely by setting it to 0? If
the connection is idle, and the Azure side is not sending keepalives (which
seems to be the case) then you should have idle-timeout turned off
completely on the proton side, otherwise it will time out eventually no
matter how
I noticed a discrepancy on how PN_DELIVERY is handled by different bindings
1. C++ - if (link is locally closed and auto_accept is set) { release the
message } else { call on_message }
2. Python - if (link is locally closed) { if (auto_accept is set) release
the message} else call on_message
3. G
On Thu, Nov 23, 2017 at 5:48 AM, Chris Richardson wrote:
> [snip: discussion of issues building on Linux Alpine]
>
> Another alternative is that we make a more official version of the source
> code hack I previously mentioned to make Proton compatible with the reduced
> (I'm not judging) musl lib
The tracker is returned when you call sender::send - it applies to the
message that you just sent. Proton does not keep track of the message for
you, because that might be a large amount of memory for applications that
don't need it - however you can keep track of it yourself. tracker is a
subclass
Welcome aboard!
On Thu, Nov 16, 2017 at 3:52 AM, Keith W wrote:
> Indeed, welcome!
>
> On 16 November 2017 at 07:57, Lorenz Quack wrote:
> > Welcome Chris,
> >
> > Good to have you on the team!
> >
> > On Wed, Nov 15, 2017 at 7:02 PM, Adel Boutros
> wrote:
> >
> >> Welcome Chris!!
> >> ___
On Thu, Nov 9, 2017 at 3:17 PM, Alan Conway wrote:
> Apologies for the long delay, this is a bug and was reported previously:
> https://issues.apache.org/jira/browse/PROTON-1429
>
> I am fixing it now, watch the JIRA to be notified when it is fixed. You
> can get the latest code
pacemaker using "apt-get install
> pacemaker".
>
> If you could give me some hints what to do to get it run it would be
> welcome.
>
> Thanks,
> Andreas
>
> On Wed, Nov 8, 2017 at 8:01 PM, Alan Conway wrote:
>
> > rgmanager has been replaced by pacemaker on R
+1
Ran the basic tests against dispatch, C++, python.
On Tue, Nov 14, 2017 at 3:36 PM, Chuck Rolke wrote:
> +1
>
> * Verified signature and (not zipped) hashes
> * Compiled ProtonCpp, ProtonPython, AmqpNetLite shims
> * Ran types test against Artemis broker
> * Ran types and large message tes
On Fri, Nov 10, 2017 at 8:28 AM, Jiri Danek < jda...@redhat.com > wrote:
> On Fri, Nov 10, 2017 at 1:10 PM, Alessio Gottardo
> > wrote:
> >
> > Out of curiosity is there a specific reason for `panic`ing in the
> > `default` case instead of returning an `error`?I just became aware of
> this
> > `r
Apologies for the long delay, this is a bug and was reported previously:
https://issues.apache.org/jira/browse/PROTON-1429
I am fixing it now, watch the JIRA to be notified when it is fixed. You can
get the latest code direct from git, the "go get" repo will be updated with
the next release of pro
rgmanager has been replaced by pacemaker on RHEL7, I'm not sure what is
available on Ubuntu. There is no out-of-the-box integration with pacemaker
or other cluster managers, but all that is needed is some configuration and
a couple of scripts to enable the cluster manager to start, stop and
promote
+1
built & ran self-tests for C, C++, python, ruby, go on fedora 26
built & ran C and C++ tests on gcc/clang, c++03/c++11, with address and
thread sanitizers
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, pleas
+1 - to the changes and I guess it makes sense to do it for 0.19 rather
than 18.1.
Also +1 to thinking seriously about 1.0 - maybe not 0.19, but soon. The
proton core is stable and well tested, the existing APIs aren't all exactly
what we want them to be, but they are all proven to be usable in se
ote:
> >> If the fix is quick, I prefer to have it natively in 0.18.0. Otherwise,
> I will have to have a local patch to disable it and thus will have to build
> a custom version of proton.
> >>
> >> Adel
> >>
> >> F
I'll fix the libuv proactor stuff but I'm not convinced that's a show
stopper. I'd be inclined to include it in a respin if there is one when its
ready but not hold up the release.
On Thu, Oct 19, 2017 at 10:31 PM, Andrew Stitcher
wrote:
> Some more problems found on FreeBSD and building with a
PROTON-1639 may be an issue, please check out the comments & fix for the
second half (epoll proactor bug)
https://issues.apache.org/jira/browse/PROTON-1639?focusedCommentId=16212665&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16212665
I'm not sure how common imme
I can confirm the ipv6 problem, I've opened
https://issues.apache.org/jira/browse/PROTON-1639 and I'm working on fixing
it in case of respin.
On Thu, Oct 19, 2017 at 5:19 PM, Adel Boutros wrote:
> I have a patch for the below failure (We have to re add -pthread to
> CMAKE_C_FLAGS).
>
> But now I
There is something funny here - you appear to have both ruby and rubygems
executables installed, but are missing rubygems ruby package. Can you make
sure that the packages "ruby" and "rubygems" are either fully installed or
fully uninstalled and try again from a clean build? If the problem persists
You can use `cmake -DBUILD_RUBY=NO` to skip the build. I see that on older
platforms the presence of `ruby` doesn't automatically imply the presence
of rubygems as it does on newer ones. I'll update the ruby-detect logic in
case there is a respin.
On Thu, Oct 19, 2017 at 4:42 PM, Adel Boutros wro
The problem is confusion between URL and Go "connection address". Electron
lets Go do all the networking and only handles AMQP encoding/decoding, so
electron.Container.Dial() is just a shortcut for conn := net.Dial(...);
proton.Container.Connection(conn, [options...])
So the network address to Dia
Ruby is done, we are closing the final C/C++ issues today I hope, so should
be very soon now.
On Wed, Oct 11, 2017 at 4:16 AM, sergio wrote:
> Any update on this. We are already in Mid-October.
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> -
an aborted=true
frame as required. Proton will never send a message consisting of a single
aborted frame.
A proton receiver will handle a message consisting of a single aborted frame
correctly - i.e. do credit calculations but consider the delivery aborted.
On Tue, Oct 3, 2017 at 10:02 AM, Ala
On Mon, Oct 2, 2017 at 6:01 PM, Rob Godfrey wrote:
> On 2 October 2017 at 23:37, Alan Conway wrote:
>
> > Trying to interpret the AMQP spec regarding credit and aborted mesages.
> >
> > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-
> > transport-v1.0-os.
Trying to interpret the AMQP spec regarding credit and aborted mesages.
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-flow-control
says this: "The *delivery-count* is initialized by the sender when a link
endpoint is created, and is incremented whenever a messag
For an overview of the router and configuration start with
http://qpid.apache.org/releases/qpid-dispatch-0.8.0/book/book.html
For your clients, there's really no configuration difference - they should
simply be pointed to the host/port of the router rather than a broker. You
can use the router to
>
>
>
> On 6 September 2017 at 20:00, Ken Giusti wrote:
>
> > Alan -
> >
> > Hate cmake? Maybe you'd be interested in automake instead.
> >
> > /me ducks
> >
> > ;)
> >
> > On Wed, Sep 6, 2017 at 2:44 PM, Alan Conway w
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 interpreter directive in some way.
>
> E.g. in dispatch there is:
>
> install(PROGRAMS
>> ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdstat
>> ${CMAKE
On Wed, 2017-08-23 at 17:58 +0100, Gordon Sim wrote:
> On 23/08/17 17:35, Steve Huston wrote:
> > - Host A wants to set up a pull route to pull messages from Host B
> > - Host A has two IP addresses assigned to it
> > - When Host A connects to B, can A specify a particular source IP address
> > th
Welcome! I was on vacation, otherwise I would have voted for you :)
On Wed, Aug 9, 2017 at 10:10 AM, Adel Boutros wrote:
> Thank you all! It has been a fun and exciting journey so far :)
>
>
> From: Ganesh Murthy
> Sent: Wednesday, August 9, 2017 3:13:31 PM
> To
1 - 100 of 620 matches
Mail list logo
