Hi Chris,
Thanks for your mail. I see the memory usage more clearly.
For the sender side, after I set a bigger capacity. I see the memory usage is
increase and decrease periodically.
But for the receiver side, the memory usage is still keeping increasing. Here
is the changed code for both
Some more problems found on FreeBSD and building with a libuv proactor
on Linux:
PROTON-1642, PROTON-1643, PROTON-1644, PROTON-1645
Everything I've found today is all either on uncommon platforms (RPi,
FreeBSD) or using the less tested libuv proactor.
So despite finding these, it's actually not
Not a vote yet:
Testing the rc on my RPi3:
OS: Raspbian Stretch (very close to Debian 9)
All goes well except for 2 failures in the ruby-data-spec test. It's
not clear to me if this is a serious issue with the ruby binding or
not.
Raised as PROTON-1640 [1].
I suspect the issue is somehow to do
On Thu, 2017-10-19 at 13:57 -0400, Ted Ross wrote:
> Adel,
>
> I saw the same error. I then noticed that I had not installed the
> cyrus-sasl packages. Once I installed these packages, the pthread-
> once
> error went away. Not that I understand why, but that's what I saw.
Could you report thi
Adel,
I saw the same error. I then noticed that I had not installed the
cyrus-sasl packages. Once I installed these packages, the pthread-once
error went away. Not that I understand why, but that's what I saw.
-Ted
On Thu, Oct 19, 2017 at 11:53 AM, Adel Boutros wrote:
> Hello again,
>
>
> I
Thus far the things noted feel like reasons to do another release,
rather than reasons to stop one thats long overdue. Based on what I've
read so far there wont be a respin.
It takes about the same amount of work [for me] to respin it as it
does to just do another release. We dont do enough releas
On Thu, 2017-10-19 at 17:36 +, Adel Boutros wrote:
> 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.
I don't think this test failure is a reason to respin.
The o
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
From: Alan Conway
Sent: Thursday, October 19, 2017 7:19:50 PM
To: users@qpid.apac
I gave things a quick look over and test earlier when trying out the
Proton 0.18.0 RC
The main issues I noticed were things I you already knew of, that:
- The console/hawtio/pom.xml version is still at -SNAPSHOT.
- The console/dispatch-dashboard/setup.py details look off in the RC.
The update on m
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
On Thu, 2017-10-19 at 16:58 +, Adel Boutros wrote:
> Hello Alan and Andrew,
>
>
> Indeed, in the attached log, I am just showing you the latest failure
> I had which is a unit test failing. As for the previous errors, I was
> able to fix them by adding "-pthread" and "-DBUILD_RUBY=NO" to my
On Thu, 2017-10-19 at 16:58 +, Adel Boutros wrote:
> Hello Alan and Andrew,
>
>
> Indeed, in the attached log, I am just showing you the latest failure
> I had which is a unit test failing. As for the previous errors, I was
> able to fix them by adding "-pthread" and "-DBUILD_RUBY=NO" to my
Hello Alan and Andrew,
Indeed, in the attached log, I am just showing you the latest failure I had
which is a unit test failing. As for the previous errors, I was able to fix
them by adding "-pthread" and "-DBUILD_RUBY=NO" to my build script.
Regards,
Adel
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
On Thu, 2017-10-19 at 16:40 +, Adel Boutros wrote:
> Re-attaching the log as it seems the mailing server rejected the
> first one.
The log isn't useful to me as you don't show the build failure. I guess
you've added your patch. Just adding to CMAKE_C_FLAGS isn't a solution
- it's a work around
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
On Thu, 2017-10-19 at 16:38 +, Adel Boutros wrote:
> Hello Andrew,
>
> Yes, we are using a gcc which we built without any patching.
Hmm, could you check that the system supplied gcc behaves differently
from your own compiled version? That might give us a clue.
>
> Just note that we are usin
Re-attaching the log as it seems the mailing server rejected the first one.
Adel
From: Adel Boutros
Sent: Thursday, October 19, 2017 6:38:58 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
Hello Andrew,
Yes, we are using a
Thanks Adel. If you have a suggested diff, feel free to send it so
those with more of a clue around these bits than me can assess things.
To be clear for everyone else: this vote remains open, please continue
to test and vote on it.
Robbie
On 19 October 2017 at 17:25, Adel Boutros wrote:
> Hell
Hello Andrew,
Yes, we are using a gcc which we built without any patching.
Just note that we are using the epoll implementation of the proactor in case it
might help the analysis.
Please also note that proton compiles successfully on windows and tests are
fully green (using Visual Studio 201
On Thu, 2017-10-19 at 16:25 +, Adel Boutros wrote:
> Hello Robbie,
>
>
> It is GCC 4.9.2 on Red Hat Enterprise Linux Server release 6.4
Are you using a custom compiler? As far as I know RHEL6 has gcc 4.4.7.
Andrew
-
To un
Hello Robbie,
It is GCC 4.9.2 on Red Hat Enterprise Linux Server release 6.4
Regards,
Adel
From: Robbie Gemmell
Sent: Thursday, October 19, 2017 6:19:38 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
Can you provide more d
I have a patch for the below failure (We have to re add -pthread to
CMAKE_C_FLAGS).
But now I have a new error in the tests related to IPv6. As my machine does not
support IPv6, I have the -cproactor-tests failing
test 21
Start 21: c-proactor-tests
21: Test command: /build-dir/proton/pro
Can you provide more detail around e.g OS, compiler, etc, so that
folks can better assess the issue, any fix needed, and whether it is
sufficient reason to respin as opposed to say, a reason to do a
0.18.1.
On 19 October 2017 at 16:53, Adel Boutros wrote:
> Hello again,
>
>
> I will have to vote
Hello again,
I will have to vote -1 here. I am having issues with openssl on Linux (I am
using openssl 1.0.2h)
[ 31%] Building C object
proton-c/CMakeFiles/qpid-proton.dir/src/reactor/connection.c.o
CMakeFiles/qpid-proton-core.dir/src/ssl/openssl.c.o: In function
`ensure_initialized':
/data/
I just got done testing the Dispatch 1.0.0-rc1 code by doing a
100-iteration run of my distribution unit test suite. Altogether, 25 tests
in there -- including one not yet checked in.
zero failures out of 2500 test-runs ---> mick says 'Good to go!"
so
Good to go!
On Wed, Oct 18, 2017
Hello,
I am trying to build proton 0.18.0 but I am facing errors with ruby-gem. Do you
know how I can deactivate this target?
[ 5%] Generating qpid_proton-0.18.0.gem
/usr/bin/gem:8:in `require': no such file to load -- rubygems (LoadError)
from /usr/bin/gem:8
make[2]: *** [proton-c/bindings/r
+1. I build it from source code and used it with Qpid C++ broker (master)
and Qpid Dispatch (1.0.0 RC1) and run my tests against them. All seems to
work fine.
On Wed, Oct 18, 2017 at 7:29 PM, Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together a first spin for a Qpid Proton 0.18.0 release,
On 18 October 2017 at 18:29, Robbie Gemmell wrote:
> Hi folks,
>
> I have put together a first spin for a Qpid Proton 0.18.0 release,
> please test it and vote accordingly.
>
> The source archive can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.18.0-rc1/
>
> The JIRAs cu
+1
- Built, installed, and ran the tests on Centos7
- Built the qpid-dispatch 1.0.0 RC against 0.18.0 and ran the full test
suite
On Wed, Oct 18, 2017 at 5:22 PM, Timothy Bish wrote:
> +1
>
> * Validated signature and checksum
> * Verified License and Notice files present
> * Built from source
Fank,
You should bear in mind that the messaging interfaces are concurrent - in
the case of your sender, the sender.send(message) call is non-blocking and
will queue messages up to the capacity of the sender (default: 50) and will
then block until the queue has a slot available. This behaviour can
Dear all,
Sorry to disturb you. I am new to Qpid.
When I tried to write a simple sender and receiver by splitting the HelloWorld
example in Qpid cpp 1.36. I met memory problem.
HelloWord1 is responsible receiving data as below:
Connection connection(broker, connectio
32 matches
Mail list logo
