ing the qpid-proton-cpp library from ubuntu packages[1], and I
> was wondering as for the interface `on_tracker_accept()` inside the
> proton::messaging_handler, how can we learn which message tracker has
> been accepted? I'm planning to integrate some callbacks for sent
> message
Hi, proton developers,
I'm using the qpid-proton-cpp library from ubuntu packages[1], and I
was wondering as for the interface `on_tracker_accept()` inside the
proton::messaging_handler, how can we learn which message tracker has
been accepted? I'm planning to integrate some callbacks for sent
I also took a look, and I don't think we have accessors for these in C++.
I raised a ticket for it:
https://issues.apache.org/jira/browse/PROTON-2139
On Thu, Oct 24, 2019 at 7:21 AM Gordon Sim wrote:
> On 18/10/2019 3:11 pm, bajanfella wrote:
> > I see that there is a
disabled
> > from the connection_options.
> > Does it sound reasonable for you? Should we create a Jira issue and
> > propose a fix?
> >
> > Thanks,
> > Ali & Rabih
> >
> > From: Rabih M
> > Sent: mercredi 13 novembre 2019 19:22
> >
t; from the connection_options.
> Does it sound reasonable for you? Should we create a Jira issue and
> propose a fix?
>
> Thanks,
> Ali & Rabih
>
> From: Rabih M
> Sent: mercredi 13 novembre 2019 19:22
> To: users@qpid.apache.org
> Subject: [Qpid-proton-cpp] Performa
d
> propose a fix?
>
> Thanks,
> Ali & Rabih
>
> From: Rabih M
> Sent: mercredi 13 novembre 2019 19:22
> To: users@qpid.apache.org
> Subject: [Qpid-proton-cpp] Performance regression found in 0.29.0
>
> Hello,
>
> We are upgrading in our code the proton versio
h M
Sent: mercredi 13 novembre 2019 19:22
To: users@qpid.apache.org
Subject: [Qpid-proton-cpp] Performance regression found in 0.29.0
Hello,
We are upgrading in our code the proton version from 0.27.0 to 0.29.0.
While running our unit tests, we found a considerable performance regression.
We
Hello,
We are upgrading in our code the proton version from 0.27.0 to 0.29.0.
While running our unit tests, we found a considerable performance
regression.
We were able to reproduce the regression in a very simple use case.
Please find the code attached.
This test takes 1 ms in the version
On 18/10/2019 3:11 pm, bajanfella wrote:
I see that there is a pn_ssl_domain_set_protocol and
pn_ssl_domain_set_ciphers in the proton-c API. There there equivalent
functionality using the C++ API? How do I get access to the pn_ssl_domain_t
struct from my CPP API?
If not an expert on the proton
I see that there is a pn_ssl_domain_set_protocol and
pn_ssl_domain_set_ciphers in the proton-c API. There there equivalent
functionality using the C++ API? How do I get access to the pn_ssl_domain_t
struct from my CPP API?
--
Sent from:
On Wed, 2019-04-03 at 15:19 +0200, Rabih M wrote:
> Hello,
>
> I am using the latest version of proton cpp 0.27.0.
>
> I have a suggestion for the signature of the messaging handler's
> methods:
> In my opinion, giving the parameters as references is error prone.
> Because
> it gives the user
ilto:acon...@redhat.com]]
Sent: 07 September 2018 16:10
To:
users@qpid.apache.org[mailto:users@qpid.apache.org][mailto:users@qpid.apache.org[mailto:users@qpid.apache.org]]
Cc: n...@gmx.es[mailto:n...@gmx.es][mailto:n...@gmx.es[mailto:n...@gmx.es]]
Subject: Re: qpid-proton-cpp decoder.cpp - possible bug?
duce 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: Re: qpid-pr
fix below introduced this new issue?
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: Re: qpid-proton-cpp decoder.cpp - possible bug?
I think this is a
This is great - many thanks for the help!
From: Alan Conway [mailto:acon...@redhat.com]
Sent: 07 September 2018 16:10
To: users@qpid.apache.org
Cc: n...@gmx.es
Subject: Re: qpid-proton-cpp decoder.cpp - possible bug?
I think this is a bug I fixed recently, it should be in the latest release
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()
Hi,
Around line 180, decoder.cpp has the following:
decoder& decoder::operator>>(scalar& x) {
internal::state_guard sg(*this);
type_id got = pre_get();
if (!type_id_is_scalar(got))
throw conversion_error("expected scalar, found "+type_name(got));
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, 2018 at 5:37 AM, Baptiste Robert <
> baptisterober...@gmail.com
> > wrote:
>
> > Hello,
> >
> > I'm encountering a crash in the proton
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
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 destroy) => the crash happen.
Where does it crash ? In *win_iocp.c*,
I do not use any kind of timer on my side, but maybe it's a similar
internal proton issue as this one :
https://issues.apache.org/jira/browse/DISPATCH-945
2018-04-18 2:21 GMT+02:00 Chris Richardson :
> A couple of suggestions spring to mind - I've experienced problems with
>
A couple of suggestions spring to mind - I've experienced problems with
timers in other libraries where a timer fires after (or indeed during) its
callback or associated data has been deleted, resulting in a segfault.
Could this be relevant? Probably capturing a core dump and inspecting with
gdb
Hello,
When I create a proton::container and use it, I have a crash when I delete
the proton object:
void pn_proactor_free(pn_proactor_t *p) {
-> DeleteTimerQueueEx(p->timer_queue, INVALID_HANDLE_VALUE);
I'm using proton 0.21 compiled in CXX03 mode.
Is anyone have an idea ?
Thank you,
Hi, Baptiste. There's something coming soon in Proton C 0.22.0 that may
help with that.
https://issues.apache.org/jira/browse/PROTON-1589
This is on master now, and the 0.22.0 release process will start this month.
On Fri, Mar 23, 2018 at 7:57 AM, Baptiste Robert
Hello,
I've an annoying issue when I define reconnect_options and call connect
method on the proton::container with this option. If the authentication is
wrong (bad password/login), I got the following error : [proton:io] - [Too
many reconnect attempts (40)]
In my use case, I really want to know
On Mon, Mar 19, 2018 at 12:07 PM, Baptiste Robert <
baptisterober...@gmail.com> wrote:
> Thank you for your answer, It fixed my issues. Maybe it's due tthe
> partial support of C++11 integrated in GCC 4.6.2.
>
In the same way, is it possible to build the last qpid-proton version with
> OpenSSL
Thank you for your answer, It fixed my issues. Maybe it's due to the
partial support of C++11 integrated in GCC 4.6.2.
In the same way, is it possible to build the last qpid-proton version with
OpenSSL 1.0.0 ? Since the 0.19 version I cannot built it, is it possible to
set a cmake variable to make
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
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. without C++11 support, and
I'm supposing that is the root cause of a lot
On 15 March 2018 at 13:42, Alan Conway wrote:
>
>
> 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
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
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 can send messages to the broker if
authenticationproviders is set to
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
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
proton::container in a separate thread, and a handler that inherate
ber...@gmail.com>
wrote:
> Hi everybody,
>
> I'm currently working with the qpid proton cpp API (0.18 version) with an
> old gcc without c++11 support. I can compile it and use the examples, but
> I'm building a multi-threaded client, where I'm trying to create new sender
-24 at 14:06 +0530, Venkat B wrote:
> > > Good day,
> > >
> > > -- Forwarded message --
> > > > From: Alan Conway <acon...@redhat.com>
> > > > To: users@qpid.apache.org
> > > > Cc:
> > > > Bcc:
> > &g
> > > To: users@qpid.apache.org
> > > Cc:
> > > Bcc:
> > > Date: Wed, 22 Mar 2017 14:09:00 -0400
> > > Subject: Re: [qpid-proton-cpp] default_container does not implement
> > > thread
> > > safety at all?
> > >
> >
> >
On Fri, 2017-03-24 at 14:06 +0530, Venkat B wrote:
> Good day,
>
> -- Forwarded message --
> > From: Alan Conway <acon...@redhat.com>
> > To: users@qpid.apache.org
> > Cc:
> > Bcc:
> > Date: Wed, 22 Mar 2017 14:09:00 -0400
> > Su
Good day,
-- Forwarded message --
> From: Alan Conway <acon...@redhat.com>
> To: users@qpid.apache.org
> Cc:
> Bcc:
> Date: Wed, 22 Mar 2017 14:09:00 -0400
> Subject: Re: [qpid-proton-cpp] default_container does not implement thread
> safety at all?
&
ent: Wednesday, March 15, 2017 10:51:24 PM
> To: users@qpid.apache.org
> Subject: Re: [qpid-proton-cpp] default_container does not implement
> thread safety at all?
>
> On Tue, 2017-03-14 at 01:23 +0200, Fj wrote:
> > Hello, I'm mightily confused.
> >
> > There's
&g
lan Conway <acon...@redhat.com>
Sent: Wednesday, March 15, 2017 10:51:24 PM
To: users@qpid.apache.org
Subject: Re: [qpid-proton-cpp] default_container does not implement thread
safety at all?
On Tue, 2017-03-14 at 01:23 +0200, Fj wrote:
> Hello, I'm mightily confused.
>
> There's
On Tue, 2017-03-14 at 01:23 +0200, Fj wrote:
> Hello, I'm mightily confused.
>
> There's
> https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/cpp/api/md
> _mt.html
> that says in no uncertain terms that I can use event_loop.inject() to
> execute a callback on the thread that runs the
On Tue, 2017-03-14 at 01:23 +0200, Fj wrote:
> ... (elided somewhat inflammatory comments)
> Am I missing something obvious,
That's difficult to say (obvious is so subjective!)
The code you are looking at implements the multithreaded API, but is
not multithreaded itself, and yes it is
Hello, I'm mightily confused.
There's
https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/cpp/api/md_mt.html
that says in no uncertain terms that I can use event_loop.inject() to
execute a callback on the thread that runs the event loop. There's an
examples/cpp/mt/broker.cpp linked from
44 matches
Mail list logo