Hello,
Is there any way to make system_tests_protocol_family test pass if the
machine does not support ipv6? is there a way cmake can detect that?
Thanks,
R
s
> in the above JIRA).
>
> I have not found a way in Python or in cmake to accurately find out if a
> machine has IPv6 turned off.
>
> I would love to hear if anybody has any ideas.
>
> Thanks.
>
> - Original Message -
> > From: "Rabih M" <rab
Apparently the mail server does not accept ".patch" attachments...
Attaching again in ".txt"
rabih
On Mon, Jun 6, 2016 at 6:43 PM, Rabih M <rabih.prom...@gmail.com> wrote:
> Hello,
>
> I made a small patch to fix some minor bugs in the dispatcher unit-tests
Hello,
I tried to launch proton 0.12.0 unit tests on Linux, everything is working
fine except when i launch SASL related unit tests in python-test.
The following 2 tests are failing when SASL is activated but are passing
when SASL is deactivated:
com> wrote:
> On 10/05/16 11:38, Rabih M wrote:
>
>> Hello,
>>
>>
>>
>> I have an issue while using proton C++ binding 0.12.0. In my use case, I
>> need to get one and only one message from a distant queue.
>>
>> But I am not able to do it
Hello again,
Did anyone had time to check my question?
Am I sending to the correct mailing list?
Thanks,
Rabih
On Tue, May 10, 2016 at 12:38 PM, Rabih M <rabih.prom...@gmail.com> wrote:
> Hello,
>
>
>
> I have an issue while using proton C++ binding 0.12.0. In my use case
Hello,
I compiled the Qpid C++ code on windows using visual studio 2013.
I have some unit tests failures, I tried to debug but it is not obvious to
find the root cause.
In qpid-client-test: The client is not able to connect to the qpid broker.
This the output I am getting:
...
test 1
Start
Hello,
I have an issue while using proton C++ binding 0.12.0. In my use case, I
need to get one and only one message from a distant queue.
But I am not able to do it with proton. I read that in the constructor of
handler I could specify that using prefetch parameter, but it is not
working.
Hello,
The question is in the title.
I am asking because we are interested in
https://issues.apache.org/jira/browse/QPID-7558
Best regards,
Rabih
of curiosity, what is your time-line for when you would like this
> > > feature to land?
> > >
> > > We were considering back porting this but there are currently no plans
> > for a
> > > 6.2.0 release and as a new feature this is not really fit for a bug fix
D-7558 (first thing tomorrow) that will
> > apply cleanly to 6.1.x, allowing you to simply checkout/build your
> > own.
> >
> > I will keep this under review. If v7.0 slips from its estimated
> > delivery date, or it makes sense to release other features early in a
>
Hello,
I compiled qpid-proton 0.16.0 with "-DSASL_IMPL=none", but i have an 3 of
qpid-dispatch 0.7.0 unit tests that are failing:
system_tests_qdstat
system_tests_sasl_plain
system_tests_deprecated
I attached the tests output.
Do you have any idea, where should i look? Is Cyrus mandatory
Hello Alan,
Thank you for your reply.
https://issues.apache.org/jira/browse/DISPATCH-631
Best regards,
Rabih
On Tue, Feb 7, 2017 at 8:56 PM, Alan Conway <acon...@redhat.com> wrote:
> On Tue, 2017-02-07 at 19:32 +0100, Rabih M wrote:
> > Hello,
> >
> > I
: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> > >
> > > On 20 January 2017 at 19:06, Gordon Sim <g...@redhat.com> wrote:
> > > > On 20/01/17 18:40, Rabih M wrote:
> > > >>
> > > >> I inserted the map directly into the O
target (for a sender) to
> be 'dynamic'. You would then inspect the remoteSource or remoteTarget
> once the link had been reemotely attached, and get its
> (server-generated) address, then use this as your reply-to.
>
> Robbie
>
> On 23 January 2017 at 11:00, Rab
Hello,
Does the java qpid broker supports Amqp management 1.0 ?
If not, are there any plans to do it?
Best regards,
Rabih
Hello,
If I understood well, Qpid-Dispatch can be managed using Amqp messages.
I saw that the management code is based on proton python binding.
Do you think it is feasible to manage the dispatch router the same way from
Qpid-Jms api?
Was there any work done in this direction before? Will it be
Hello,
Thank you for you answers.
I am trying to experiment to see if i can do it with the info you gave me.
I took a simple example to start: qdmanage -b :5672
create --type=connector role=route-container addr=broker-machine port=5673
name=rabih.connector
My goal is to imitate the behavior
differences.
I attached the amqp exchanges in both cases.
Do you think i have some missing info in my proton-j message?
Thanks,
Rabih
On Fri, Jan 20, 2017 at 7:09 PM, Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:
> On 20 January 2017 at 17:29, Rabih M <rabih.prom...@gmail.com> w
I inserted the map directly into the ObjectMessage like you told me Robbie
and it worked.
But like the proton-j case, the connector is not being created on the
Qpid-dispatch side.
I attached the amqp communication into this mail.
Best regards,
Rabih
On Fri, Jan 20, 2017 at 7:24 PM, Rabih M
Hello,
Bit of context:
I am trying to implement a connection retry mechanism using proton. A bit
similar to the failover Url in JMS...
I discovered that we can set "reconnect" option in the
connection_options.reconnect(reconnect_timer).
There are no clear documentation, how does this option
Hello,
I noticed that windows does not take into consideration the configured
connection idle_timeout if it is less than 1 second. Linux does not have
this problem.
I wrote some code to reproduce at the end of the mail.
Is it a bug ?
Best regards,
Rabih
#include
#include
#include
#include
Hello,
I am trying to implement a retry mechanism using proton. If the connection
between the amqp peers is down or the remote peer itself is down, i would
like to retry the current operation (send, receive...). A bit similar to
the failover Url in JMS...
Therefore i would like to capture only
Hello Cliff,
Here is the jira issue: https://issues.apache.org/jira/browse/PROTON-1464
Thanks,
Rabih
On Thu, Apr 13, 2017 at 10:16 PM, Cliff Jansen <cliffjan...@gmail.com>
wrote:
> This should work on Windows too.
>
> Could you please raise a JIRA? Thanks.
>
> Cliff
&g
Hello,
If you try to connect using an invalid server port on windows, the proton
client blocks for 2 seconds. On linux we do not have this problem.
Do you have any idea why?
Best regards,
Rabih
OS: Windows 7, Compiler: MSVC 2013 Version 12 Update 5, Proton: 0.22.0
Sample code:
class
Please raise a
> JIRA and we will try to fix it in 6.1.6/6.0.9/7.0.1.
>
> You can try to use BDB or Derby message store instead of JDBC one to
> work around the issue.
>
> Kind Regards,
> Alex
>
> On 5 January 2018 at 15:13, Rabih M <rabih.prom...@gmail.com> wro
Hello,
We are using Qpid java broker version 6.1.4.
Our test case:
We have a JMS client sending messages continuously in autoAck mode to a
messaging cluster. The cluster is composed of 1 dispatch router and 2 java
brokers which are connect to an Oracle Db.
At some point, the test kills a broker
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, messaging
producer, messaging consumer...). So the whole
ome voice calls to discuss more...
Best regards,
Rabih
On Tue, Feb 13, 2018 at 8:44 PM Alan Conway wrote:
> 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
> > th
Hello,
We are trying to build the latest released version of the dispatch router
1.3.0.
We are using redhat OS (2.6.32-358.el6.x86_64 GNU/Linux), GCC 4.9.2 and Python
2.7.8.
And we have 2 failing unit tests:
system_tests_two_routers:
Hello,
What Olivier was proposing is more at the level of the C++ proton binding.
What we would like to do is:
Instead of taking a vector of fixed fail-over urls in the
reconnect_options, we would like the reconnect_options to take an
std::function that returns a URL. This function will be called
Hello,
I adapted the code like we said in the last meeting and it worked without
crashes.
So the rule that i deduce is that "we cannot copy any proton objet outside
of the handler's class".
I attached the corrected code for future reference.
Thanks,
Rabih
On Wed, Mar 27, 2019 at 5:1
you
confirm?
Best regards,
Rabih
On Wed, Mar 27, 2019 at 5:31 PM Rabih M wrote:
> Hello,
>
> I am using proton cpp version 0.27.0.
> I have a random crash when calling stop on the container after closing the
> connection.
> Please find the attached the code and the sta
Hello,
I am using proton cpp version 0.27.0.
I have a random crash when calling stop on the container after closing the
connection.
Please find the attached the code and the stack.
In the doc, it is said that the container object is thread safe but
apparently there is flaw...
Can you please
Hello,
I am using proton cpp version 0.27.0.
We found a random failure in our code in proton sometime ago.
I was able to reproduce using simple code against a java broker. Please
find attached the code and the stack.
The frequency is lower with the simplified code but we are still
t; >
> > 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 taking a vector of fixed fai
.h...@murex.com>> wrote:
> >
> > > Hello Alan,
> > >
> > > Do you have any updates concerning the proposition to update the
> > > reconnect options in Proton-C?
> > > Is it planned and if yes do you have an idea when?
> > >
> >
>
Hello,
Any ideas about the mail below?
Do i create Jira issue?
Best Regards,
Rabih
On Mon, May 6, 2019 at 5:33 PM Rabih M wrote:
> Hello,
>
> We are using proton cpp 0.27.1 with visual studio 2013.
>
> We have the attached Main.cpp that is hanging on line 58 on win
Hello Cliff,
After spending more time debugging, I think we found where the real problem
comes from:
I attached a simplified use case in the Main.cpp, Broker.hpp.
When we call delivery.work_queue().add() line 35 of Main.cpp, we get an
random segfault and if we replace it instead by a
Hello,
We are using proton 0.27.0.
We are facing segfaults due to race conditions on the ref counting
mechanism of proton C at destruction time.
We are only using proton objects in the handler, however, at destruction
time, there is a race condition on the reference counter between the proton
Hello,
We are using proton cpp 0.27.1 with visual studio 2013.
We have the attached Main.cpp that is hanging on line 58 on windows
randomly.
As if line 57 was not executed.
For the working case we have the following logs :
broker on_container_start
client on_container_start
[0260A1C0]:
Hello,
The flag proton::receiver_options().auto_accept(true), if set does not
guarantee that the user can't make any action on the delivery.
There is a race condition on who sends the request before, the user or
proton.
The following example fails randomly (The example is taken from the
Hello,
We are using Qpid dispatch router 1.7, Qpid broker 7.1.3 on redhat linux
rhel 6.4.
Use case description:
We have a cluster of 2 dispatch routers and 2 brokers. A sharded queue
"myQueue" on the 2 brokers.
Here is an illustration:
[image: Diagram.jpg]
The producer produces 2 messages, the
Re-attached conf files with .txt extension.
On Thu, Jul 11, 2019 at 4:36 PM Rabih M wrote:
> Hello,
>
> We are using Qpid dispatch router 1.7, Qpid broker 7.1.3 on redhat linux
> rhel 6.4.
>
> Use case description:
> We have a cluster of 2 dispatch routers and 2 bro
n find attached the new config files.
Is this the correct way to resolve this kind of problem? Does it sound
reasonable to you?
Best regards,
Rabih and Ali
On Thu, Jul 11, 2019 at 5:50 PM Ganesh Murthy wrote:
>
>
> On Thu, Jul 11, 2019 at 10:37 AM Rabih M wrote:
>
>> Hello,
&
stroyed in a
> non-callback thread. Alternatively, you can use dumb pointers to the
> Proton objects and use some application mechanism (mutex, condition
> variable...) to allow the non-callback thread to know when the pointer to
> the Proton object is valid.
>
> Cliff
>
> On
2019 at 1:26 PM Rabih M wrote:
>
> > Hello,
> >
> > We are testing with the trace+ log. We will brief you of the results when
> > they are ready.
> >
> > Our goal is not to load balance equally the messages between the
> consumers
> > but we w
er message knowing that the link capacity of the listener
is 1?
Thanks for your explanations and help,
Best regards,
Rabih
On Wed, Jul 17, 2019 at 6:46 PM Ted Ross wrote:
>
>
> On Wed, Jul 17, 2019 at 12:00 PM Rabih M wrote:
>
>> Hello,
>>
>> We tested with LinkCapa
calculation, we do not want to block
the message in the outbound queue knowing there is another idle consumer.
Is there any special configuration for this?
Best regards,
Rabih
On Fri, Jul 12, 2019 at 7:26 PM Ganesh Murthy wrote:
> On Fri, Jul 12, 2019 at 11:29 AM Rabih M wrote:
>
>
and dispatches them to the
free workers and at the same time it can monitor the load to upscale and
downscale the workers depending on the work received...
Thanks for your help,
Best regards,
Rabih
On Fri, Jul 19, 2019 at 6:02 PM Ted Ross wrote:
> On Fri, Jul 19, 2019 at 7:50 AM Rabih M wr
Hello,
Thanks for the prompt responses.
Just for context:
The version we are using in production is the Qpid dispatch 1.5.0.
Our architecture consists of a dispatch router which is a facade for all
consumers and producers. Behind the dispatch router, we have one or
multiple brokers.
The
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
oton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475>
> which is taking some time.
>
> What we would like is to avoid initializing ssl when it’s disabled from
> the connection_options.
> Does it sound reasonable for you? Should we create a Jira issue an
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
> >
Hello,
We (Murex) are very excited about this new imperative API project.
We are using proton C++ on the client side for some years now and we
experienced the difficulties this model has, as Justin described in his
first mail.
On our side, we began implementing the new API in the C++ language and
Hello,
I will share our "work in progress" for the C++ implementation even if it
is not ready yet: https://github.com/rabih-mourad/qpid-imperative-proton
There is plenty of refactoring to do and API alignment to make...
Best regards,
Rabih
On Mon, Jan 27, 2020 at 4:35 PM Rabi
Hello,
I am using proton cpp 0.27.1.
While working on the C++ imperative API, I encountered a problem while
using container.stop.
Please find the test code attached (a simplified version of the current
implementation).
I attached the core I am getting too.
The problem:
In the example I
57 matches
Mail list logo
