Re: [Dispatch 1.2.0] Wrong download link in the web page ?

[Adel Boutros]

Hello,

It could also be a proxy issue 

I had it before when I was in my previous company and we were behind a proxy.

Regards,
Adel

From: Ken Giusti 
Sent: Thursday, July 5, 2018 3:50 PM
To: users
Subject: Re: [Dispatch 1.2.0] Wrong download link in the web page ?

Hi Olivier,

When I tried going through the web page and did get a valid tar file.
Using the download link from that page redirects me to one of several
recommended mirror sites.  Perhaps the mirror site you ended up on has a
corrupted file?

Can you let me know which mirror site you ended up on?   thanks


On Thu, Jul 5, 2018 at 9:31 AM, VERMEULEN Olivier <
olivier.vermeu...@murex.com> wrote:

> Hello,
>
> When downloading the latest version of the dispatch-router from the web
> page: https://qpid.apache.org/releases/qpid-dispatch-1.2.0/index.html
> I get an artifact that I can't even untar...  gzip: stdin: not in gzip
> format
> Note that on the other hand I have no problems when downloading it from
> this link: http://archive.apache.org/dist/qpid/dispatch/1.2.0/qpid-
> dispatch-1.2.0.tar.gz
>
> Regards,
> Olivier
> ***
>
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not
> the intended recipient you are not authorised to distribute, copy or use
> this e-mail or any attachment to it. Murex cannot guarantee that it is
> virus free and accepts no responsibility for any loss or damage arising
> from its use. If you have received this e-mail in error please notify
> immediately the sender and delete the original email received, any
> attachments and all copies from your system.
>



--
-K

Re: Welcome Chris Richardson as an Apache Qpid committer

[Adel Boutros]

Welcome Chris!!

From: Chris Richardson 
Sent: Wednesday, November 15, 2017 3:20:43 PM
To: users
Subject: Re: Welcome Chris Richardson as an Apache Qpid committer

Thanks all! I do promise to execute this office to the best of my ability
etc etc so help me Qpid.

On 15 November 2017 at 13:58, Chuck Rolke  wrote:

> What he said. Welcome, Chris!
>
> - Original Message -
> > From: "Robbie Gemmell" 
> > To: users@qpid.apache.org
> > Sent: Wednesday, November 15, 2017 5:19:23 AM
> > Subject: Welcome Chris Richardson as an Apache Qpid committer
> >
> > The Qpid PMC have voted to grant commit rights to Chris Richardson in
> > recognition of continued contributions to the project.
> >
> > Welcome, Chris!
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>


--

*Chris Richardson*, System Architect
c...@fourc.eu


*FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norwaywww.fourc.eu
*

*Follow us on LinkedIn , Facebook
, Google+  and Twitter
!*

Re: Proposed update to minimum tool requirements for proton-c

[Adel Boutros]

+1 for the propositions.

How about a 1.0 release? Is proton mature enough for a major release?

Adel

From: Robbie Gemmell 
Sent: Friday, October 20, 2017 11:22:41 PM
To: users@qpid.apache.org
Subject: Re: Proposed update to minimum tool requirements for proton-c

On 20 October 2017 at 21:14, Timothy Bish  wrote:
> On 10/20/2017 03:47 PM, Andrew Stitcher wrote:
>>
>> In the course of the 0.18 release process I've been looking at the
>> minimum build tool versions supported - specifically CMake and C/C++
>> compilers. I've reached the following conclusions:
>>
>> We should move to a minimum supported cmake of 2.8.12.2, gcc 4.4.7 &
>> Visual Studio 2010.
>>
>>   - The oldest Linux distributions in large scale use here seem to be
>> RHEL 6/CentOS 6, Ubuntu 1404, Debian 8.
>> These all support either this or newer versions of cmake/gcc.
>>
>> Visual Studio 2010 is already fairly old and comparable in age to gcc
>> 4.4.7.
>>
>> The benefit of this would be to simplify the CMake build system:
>>
>> - Removing some early gcc specific build code
>> - Allowing us to use some simplifying CMake Modules
>> - Allow us to rely on some better cmake functions
>>
>> For Visual Studio it will simplify the compilers we need to test, I'd
>> suggest we build/test using VS 2010, VS 2013 & VS 2017.
>>
>> [VS 2010 because it's the oldest we support; VS 2013 because it
>> supports a pretty good subset of C99 and C++11 & VS 2017 because it is
>> the newest VS (with excellent C++11).]
>>
>> Unless anyone objects I will do the substantive part of this next week,
>> before the suggested 0.18.1 release, that is:
>>
>> - Update cmake_minimum() statements in the build files.
>> - Remove the special case code for gcc earlier than 4.4
>>
>> There's nothing specific to do for VS except document that 2010 is the
>> earliest version that we will keep on making work.
>>
>> So, thoughts, suggestions, and more particularly objections.
>>
>> Andrew
>>
>>
> While I have no objections to the change in general, it'd be a bit
> surprising to me as a user to have these sorts of changes go into an 0.18.1
> release where I'd really be expecting only minor tweaks / bug fix type
> changes.  Changing the supported tooling versions seems like something that
> really calls for a 0.19.0 release (that being the closest equivalent of a
> major version, given the 0.x designation).
>
> --
> Tim Bish
>

I thought the same as I read the suggestion, the changes sound fine
but seem more suited to a 0.19.0 than a 0.18.1.

Robbie

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Apache Qpid Proton 0.18.0

[Adel Boutros]

Fine for me :)

From: Robbie Gemmell <robbie.gemm...@gmail.com>
Sent: Friday, October 20, 2017 7:04:52 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0

I still feel the same after the latest reports/discussions, the
release will proceed unless something new comes up that convinces
otherwise.

Many people have tested the RC with success, other components await
its release (e.g Dispatch 1.0.0 requires it), and there are existing
users who can't use the current 0.17.0 release on their systems
anymore and need something new (count me among them).

I will do 0.18.1 within a week or two after more fixes and
improvemements to some of the issues noted are available and have had
time to settle.

Robbie

On 19 October 2017 at 18:52, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> 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 releases of Proton.
> I'll happily do another release soon, particularly once other issues
> and fixes have inevitably appeared.
>
> Robbie
>
> On 19 October 2017 at 18:36, Adel Boutros <adelbout...@live.com> 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.
>>
>> Adel
>> 
>> From: Alan Conway <acon...@redhat.com>
>> Sent: Thursday, October 19, 2017 7:19:50 PM
>> To: users@qpid.apache.org
>> Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
>>
>> 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 <adelbout...@live.com> wrote:
>>
>>> 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/proton-c/src/tests/c-proactor-tests
>>> 21: Test timeout computed to be: 1500
>>> 21: TEST: test_inactive()
>>> 21: TEST: test_interrupt_timeout()
>>> 21: TEST: test_errors()
>>> 21: TEST: test_proton_1586()
>>> 21: TEST: test_client_server()
>>> 21: TEST: test_connection_wake()
>>> 21: TEST: test_ipv4_ipv6()
>>> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:148: check
>>> failed: want PN_LISTENER_OPEN got PN_LISTENER_CLOSE [test_ipv4_ipv6()]
>>> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:626: check
>>> failed: Unexpected condition - proton:io:Address family for hostname not
>>> supported - connect to  ::1:59983 [test_ipv4_ipv6()]
>>> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:627: check
>>> failed: Unexpected condition - proton:io:Connection refused - disconnected
>>> :59983 [test_ipv4_ipv6()]
>>> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:628: check
>>> failed: Unexpected condition - proton:io:Address family for hostname not
>>> supported - connect to  ::1:43094 [test_ipv4_ipv6()]
>>> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:631: check
>>> failed: 'refused' not in 'Address family for hostname not supported -
>>> connect to  ::1:58818' [test_ipv4_ipv6()]
>>> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:641: check
>>> failed: want PN_LISTENER_CLOSE got PN_PROACTOR_INACTIVE [test_ipv4_ipv6()]
>>> 21: FAIL: test_ipv4_ipv6() (6 errors)
>>> 21: TEST: test_release_free()
>>> 21: TEST: test_ssl()
>>> 21: TEST: test_proactor_addr()
>>> 21: TEST: test_parse_addr()
>>> 21: TEST: test_netaddr()
>>> 21: TEST: test_disconnect()
>>> 21: TEST: test_abort()
>>> 21: TEST: test_refuse()
>>> 21: TEST: test_message_stream()
>>> 21/25 Test #21: c-proactor-tests .***Failed0.10 sec
>>>
>>> Regards,
>>> Adel
>>>
>>> 
>>> From: Adel Boutros <adelbout...@live.com>
>>> Sent: Thursday, October 19, 2017 5:53:47 PM
>>> To: users@qpid.apache.org

Re: [VOTE] Release Apache Qpid Proton 0.18.0

[Adel Boutros]

Hello Alan,


The commits you did for PROTON-1639 do actually fix the errors I was having 
with IPv6.

After using the fix, all my tests are successful. So I would vote +1 if this 
fix had been there (Of course my vote should not be blocking in any case).


Regards,

Adel


From: Alan Conway <acon...@redhat.com>
Sent: Friday, October 20, 2017 4:02:09 PM
To: users@qpid.apache.org; Andrew Stitcher; Clifford Jansen; Robbie Gemmell
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0

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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16212665

I'm not sure how common immediate errors from a non-blocking connect() are
- the disabled-IPv6 case is the only one I've seen so far, but there may be
others. Most  "normal" network failures (bad address, nobody listening on
port, no route etc.) are not detected immediately and are handled correctly.

On Fri, Oct 20, 2017 at 8:35 AM, Adel Boutros <adelbout...@live.com> wrote:

> Hello,
>
> I am wondering if all those who casted the votes or will do so have tested
> the different proactor implementations?
> From the voting replies this is not clear.
>
> In my case, I am being defaulted to the epoll as I haven't installed libuv
> yet.
>
> Regards,
> Adel
> 
> From: Andrew Stitcher <astitc...@apache.org>
> Sent: Thursday, October 19, 2017 11:31:07 PM
> To: users@qpid.apache.org
> Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
>
> 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 clear to me whether they
> are really important enough to nix the release.
>
> What do others think? For the moment I think I'm going to abstain.
>
> Andrew
>
> On Wed, 2017-10-18 at 18:29 +0100, 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 currently assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231
> > 3720=12338903
> >
> > It is tagged as 0.18.0-rc1.
> >
> > Regards,
> > Robbie
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Qpid Java Broker 6.1.4] JDBC fixes

[Adel Boutros]

Thanks Keith!


Regards,

Adel


From: Keith W <keith.w...@gmail.com>
Sent: Friday, October 20, 2017 9:57:56 AM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.1.4] JDBC fixes

Hi Adel



On 18 October 2017 at 11:39, Adel Boutros <adelbout...@live.com> wrote:
> Hello guys,
>
>
> While testing the tableNamePrefix, we noticed a bug and a very slow 
> performance on Oracle Database.
>
> I have submitted 2 jiras one for each and a pull request on the master of 
> qpid-broker-j.
>

Belated thanks.

>
> So I was wondering if they are accepted if it is possible to backport them to 
> 6.1 branch and release 6.1.5 with these fixed?
>

Yes, that should be no problem.   There are a couple of things we
would like to include in a 6.1,x defect fix.  Making these part of
that should be no problem.  We regard to timing, hands are full at the
moment with the Qpid Broker v7 (hopefully there will be an RC out in
just over a week), after that attention will turn to the Qpid JMS
Client AMQP 0-x (the 6.3.0 release - mainly to completely cleanly
separate from the Broker J) and the defect fixes due on the 6.1.x
line.

>
> https://issues.apache.org/jira/browse/QPID-7973
>
> https://issues.apache.org/jira/browse/QPID-7974
>
>
> PS 1: Do not hesitate to change my commits or propose enhancements.
>
> PS 2: Is travis connected at qpid-broker-j on github so I can see if my pull 
> request does not fail the build?
>

We use Apache CI instance.

https://builds.apache.org/view/M-R/view/Qpid/

Sometimes we do see spurious failures on some of the slower slaves.


>
> Regards,
>
> Adel

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Apache Qpid Proton 0.18.0

[Adel Boutros]

Hello,

I am wondering if all those who casted the votes or will do so have tested the 
different proactor implementations?
>From the voting replies this is not clear.

In my case, I am being defaulted to the epoll as I haven't installed libuv yet.

Regards,
Adel

From: Andrew Stitcher 
Sent: Thursday, October 19, 2017 11:31:07 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0

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 clear to me whether they
are really important enough to nix the release.

What do others think? For the moment I think I'm going to abstain.

Andrew

On Wed, 2017-10-18 at 18:29 +0100, 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 currently assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231
> 3720=12338903
>
> It is tagged as 0.18.0-rc1.
>
> Regards,
> Robbie
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Apache Qpid Proton 0.18.0

[Adel Boutros]

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 <acon...@redhat.com>
Sent: Thursday, October 19, 2017 7:19:50 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0

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 <adelbout...@live.com> wrote:

> 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/proton-c/src/tests/c-proactor-tests
> 21: Test timeout computed to be: 1500
> 21: TEST: test_inactive()
> 21: TEST: test_interrupt_timeout()
> 21: TEST: test_errors()
> 21: TEST: test_proton_1586()
> 21: TEST: test_client_server()
> 21: TEST: test_connection_wake()
> 21: TEST: test_ipv4_ipv6()
> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:148: check
> failed: want PN_LISTENER_OPEN got PN_LISTENER_CLOSE [test_ipv4_ipv6()]
> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:626: check
> failed: Unexpected condition - proton:io:Address family for hostname not
> supported - connect to  ::1:59983 [test_ipv4_ipv6()]
> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:627: check
> failed: Unexpected condition - proton:io:Connection refused - disconnected
> :59983 [test_ipv4_ipv6()]
> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:628: check
> failed: Unexpected condition - proton:io:Address family for hostname not
> supported - connect to  ::1:43094 [test_ipv4_ipv6()]
> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:631: check
> failed: 'refused' not in 'Address family for hostname not supported -
> connect to  ::1:58818' [test_ipv4_ipv6()]
> 21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:641: check
> failed: want PN_LISTENER_CLOSE got PN_PROACTOR_INACTIVE [test_ipv4_ipv6()]
> 21: FAIL: test_ipv4_ipv6() (6 errors)
> 21: TEST: test_release_free()
> 21: TEST: test_ssl()
> 21: TEST: test_proactor_addr()
> 21: TEST: test_parse_addr()
> 21: TEST: test_netaddr()
> 21: TEST: test_disconnect()
> 21: TEST: test_abort()
> 21: TEST: test_refuse()
> 21: TEST: test_message_stream()
> 21/25 Test #21: c-proactor-tests .***Failed0.10 sec
>
> Regards,
> Adel
>
> 
> From: Adel Boutros <adelbout...@live.com>
> Sent: Thursday, October 19, 2017 5:53:47 PM
> To: users@qpid.apache.org
> Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
>
> 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/jenkins-slave/home/workspace/proton-acceptance/
> proton-workspace/qpid-proton-0.18.0-rc1/proton-c/src/ssl/openssl.c:1505:
> undefined reference to `pthread_once'
> collect2: error: ld returned 1 exit status
>
>
> Regards,
>
> Adel
>
> 
> From: Adel Boutros
> Sent: Thursday, October 19, 2017 5:42:01 PM
> To: users@qpid.apache.org
> Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
>
>
> 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/ruby/qpid_proton-0.18.0.gem] Error 1
> make[1]: *** [proton-c/bindings/ruby/CMakeFiles/ruby-gem.dir/all] Error 2
>
>
> Regards,
>
> Adel
>
> 
> From: Jakub Scholz <ja...@scholz.cz>
> Sent: Thursday, October 19, 2017 5:04:59 PM
> To: users@qpid.apache.org
> Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
>
> +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 <robbie.gemm...@gmail.com>
> wrote:
>
> > Hi folks,
> >
> > I have put together a first sp

Re: [VOTE] Release Apache Qpid Proton 0.18.0

[Adel Boutros]

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


From: Andrew Stitcher <astitc...@apache.org>
Sent: Thursday, October 19, 2017 6:50:27 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0

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 actually add it to the cmake command line without patching
anything and I think it will work.

Andrew


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Apache Qpid Proton 0.18.0

[Adel Boutros]

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 2013)


You will find attached the full build log for proton on Linux.


Regards,

Adel


From: Andrew Stitcher <astitc...@apache.org>
Sent: Thursday, October 19, 2017 6:35:15 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0

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 unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Apache Qpid Proton 0.18.0

[Adel Boutros]

Hello Robbie,


It is GCC 4.9.2 on Red Hat Enterprise Linux Server release 6.4


Regards,

Adel


From: Robbie Gemmell <robbie.gemm...@gmail.com>
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 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 <adelbout...@live.com> wrote:
> 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/jenkins-slave/home/workspace/proton-acceptance/proton-workspace/qpid-proton-0.18.0-rc1/proton-c/src/ssl/openssl.c:1505:
>  undefined reference to `pthread_once'
> collect2: error: ld returned 1 exit status
>
>
> Regards,
>
> Adel
>
> 
> From: Adel Boutros
> Sent: Thursday, October 19, 2017 5:42:01 PM
> To: users@qpid.apache.org
> Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
>
>
> 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/ruby/qpid_proton-0.18.0.gem] Error 1
> make[1]: *** [proton-c/bindings/ruby/CMakeFiles/ruby-gem.dir/all] Error 2
>
>
> Regards,
>
> Adel
>
> 
> From: Jakub Scholz <ja...@scholz.cz>
> Sent: Thursday, October 19, 2017 5:04:59 PM
> To: users@qpid.apache.org
> Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0
>
> +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 <robbie.gemm...@gmail.com>
> 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 currently assigned are:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12313720=12338903
>>
>> It is tagged as 0.18.0-rc1.
>>
>> Regards,
>> Robbie
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Apache Qpid Proton 0.18.0

[Adel Boutros]

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/proton-c/src/tests/c-proactor-tests
21: Test timeout computed to be: 1500
21: TEST: test_inactive()
21: TEST: test_interrupt_timeout()
21: TEST: test_errors()
21: TEST: test_proton_1586()
21: TEST: test_client_server()
21: TEST: test_connection_wake()
21: TEST: test_ipv4_ipv6()
21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:148: check failed: 
want PN_LISTENER_OPEN got PN_LISTENER_CLOSE [test_ipv4_ipv6()]
21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:626: check failed: 
Unexpected condition - proton:io:Address family for hostname not supported - 
connect to  ::1:59983 [test_ipv4_ipv6()]
21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:627: check failed: 
Unexpected condition - proton:io:Connection refused - disconnected :59983 
[test_ipv4_ipv6()]
21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:628: check failed: 
Unexpected condition - proton:io:Address family for hostname not supported - 
connect to  ::1:43094 [test_ipv4_ipv6()]
21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:631: check failed: 
'refused' not in 'Address family for hostname not supported - connect to  
::1:58818' [test_ipv4_ipv6()]
21: /qpid-proton-0.18.0-rc1/proton-c/src/tests/proactor.c:641: check failed: 
want PN_LISTENER_CLOSE got PN_PROACTOR_INACTIVE [test_ipv4_ipv6()]
21: FAIL: test_ipv4_ipv6() (6 errors)
21: TEST: test_release_free()
21: TEST: test_ssl()
21: TEST: test_proactor_addr()
21: TEST: test_parse_addr()
21: TEST: test_netaddr()
21: TEST: test_disconnect()
21: TEST: test_abort()
21: TEST: test_refuse()
21: TEST: test_message_stream()
21/25 Test #21: c-proactor-tests .***Failed0.10 sec

Regards,
Adel


From: Adel Boutros <adelbout...@live.com>
Sent: Thursday, October 19, 2017 5:53:47 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0

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/jenkins-slave/home/workspace/proton-acceptance/proton-workspace/qpid-proton-0.18.0-rc1/proton-c/src/ssl/openssl.c:1505:
 undefined reference to `pthread_once'
collect2: error: ld returned 1 exit status


Regards,

Adel


From: Adel Boutros
Sent: Thursday, October 19, 2017 5:42:01 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0


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/ruby/qpid_proton-0.18.0.gem] Error 1
make[1]: *** [proton-c/bindings/ruby/CMakeFiles/ruby-gem.dir/all] Error 2


Regards,

Adel


From: Jakub Scholz <ja...@scholz.cz>
Sent: Thursday, October 19, 2017 5:04:59 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Proton 0.18.0

+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 <robbie.gemm...@gmail.com>
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 currently assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12313720=12338903
>
> It is tagged as 0.18.0-rc1.
>
> Regards,
> Robbie
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Qpid Java Broker 6.1.4] Some expections are hidden

[Adel Boutros]

Sorry Keith but I didn't have enough time to create the Jira or provide a fix :(


From: Keith W <keith.w...@gmail.com>
Sent: Wednesday, October 18, 2017 7:02:40 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.1.4] Some expections are hidden

I raised this as QPID-7979.

On 16 October 2017 at 12:34, Keith W <keith.w...@gmail.com> wrote:
> Hi Adel
>
> Please raise a JIRA. Include  a patch or pull request if you like.
> I'll try to include in v7.0.
>
> cheers Keith
>
> On 16 October 2017 at 12:06, Adel Boutros <adelbout...@live.com> wrote:
>> No, this was the only case I hit while testing my use case.
>>
>>
>> Regards,
>>
>> ADel
>>
>> 
>> From: Rob Godfrey <rob.j.godf...@gmail.com>
>> Sent: Monday, October 16, 2017 12:07:56 PM
>> To: users@qpid.apache.org
>> Subject: Re: [Qpid Java Broker 6.1.4] Some expections are hidden
>>
>> To my knowledge this is not deliberate, it's a bug :-) It looks like this
>> particular case has been this way since at least 2014...
>>
>> Have you found any other cases?
>>
>> -- Rob
>>
>>
>>
>> On 16 October 2017 at 11:22, Adel Boutros <adelbout...@live.com> wrote:
>>
>>> Hello,
>>>
>>>
>>> While using the Qpid Java Broker, I have noticed that sometimes the causes
>>> of the exceptions are silenced and thus I don't know why my broker failed.
>>> I had to remote debug it to find out.
>>>
>>> I wanted to know if this was on purpose or not?
>>>
>>>
>>> You can check for example: GenericJDBCMessageStore.java (line 107)
>>>
>>>
>>> Exception shown
>>>
>>> --
>>>
>>> Failed to create connection provider for connectionUrl:
>>> jdbc:derby://localhost:10452/sample and username: user
>>>
>>>
>>> Exception after remote debugging
>>>
>>> ---
>>>
>>> Unable to open a test connection to the given database. JDBC url =
>>> jdbc:derby://localhost:10452/sample, username = user. Terminating
>>> connection pool. Original Exception: --
>>> java.sql.SQLNonTransientConnectionException: Password length (0) is
>>> outside the range of 1 to 255.
>>> at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
>>> Source)
>>> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
>>> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
>>> at java.sql.DriverManager.getConnection(DriverManager.java:664)
>>> at java.sql.DriverManager.getConnection(DriverManager.java:247)
>>> at com.jolbox.bonecp.BoneCP.obtainRawInternalConnection(BoneCP.java:256)
>>>
>>>
>>> Regards,
>>>
>>> Adel
>>>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

[Qpid Java Broker 6.1.4] JDBC fixes

[Adel Boutros]

Hello guys,


While testing the tableNamePrefix, we noticed a bug and a very slow performance 
on Oracle Database.

I have submitted 2 jiras one for each and a pull request on the master of 
qpid-broker-j.


So I was wondering if they are accepted if it is possible to backport them to 
6.1 branch and release 6.1.5 with these fixed?


https://issues.apache.org/jira/browse/QPID-7973

https://issues.apache.org/jira/browse/QPID-7974


PS 1: Do not hesitate to change my commits or propose enhancements.

PS 2: Is travis connected at qpid-broker-j on github so I can see if my pull 
request does not fail the build?


Regards,

Adel

Re: [Qpid Java Broker 6.1.4] Broker is ready even if an error is occuring on startup and failStartupWithErroredChild set to true

[Adel Boutros]

I agree with your proposition around the virtual host node code changes.


I have created a jira for it:

https://issues.apache.org/jira/browse/QPID-7972


Regards,

Adel


From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Monday, October 16, 2017 3:32:32 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.1.4] Broker is ready even if an error is 
occuring on startup and failStartupWithErroredChild set to true

On 16 October 2017 at 13:08, Adel Boutros <adelbout...@live.com> wrote:

> Hello Rob,
>
> If a virtual host is not available, then all queues and persisted messages
> are currently unavailable and the broker can be considered in a critical
> state due to the messages unavailability.
>
> Is there a way to enforce that a broker will fail to startup unless all of
> its virtual host are started correctly via an option?
>
>
Not to my knowledge, no (and in some cases with HA, the vhost won't be up
unless this particular broker is the current master).  I think there would
need to be a change to the standard virtual host node code so that if there
is an error when the underlying virtual host is opened, then the virtual
host node itself is put into the errored state - this would cover the
"normal" (non-HA) case while still allowing HA virtual host nodes to not
block the broker coming up..

-- Rob


> Regards,
> Adel
> 
> From: Rob Godfrey <rob.j.godf...@gmail.com>
> Sent: Monday, October 16, 2017 11:50:34 AM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker 6.1.4] Broker is ready even if an error is
> occuring on startup and failStartupWithErroredChild set to true
>
> Hi Adel,
>
> I think broker.failStartupWithErroredChild=true will only cause the broker
> to fail if a *direct* child of the broker fails to start, the vhost is a
> child of the vhostnode, so if the vhost node starts up, the broker doesn't
> fail.
>
> -- Rob
>
> On 16 October 2017 at 11:16, Adel Boutros <adelbout...@live.com> wrote:
>
> > Hello,
> >
> >
> > Using the Qpid Java Broker 6.1.4, I have noticed that even if i specify
> > "set QPID_OPTS=-Dbroker.failStartupWithErroredChild=true" and my JDBC
> > virtual host cannot start, then the broker is set to ready.
> >
> >
> > Is this expected?
> >
> >
> > 2017-10-16 11:11:02,520 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject)
> > - Failed to open object with name 'default'.  Object will be put into
> ERROR
> > state.
> > org.apache.qpid.server.configuration.IllegalConfigurationException:
> > Attribute 'tableNamePrefix' instance of org.apache.qpid.server.
> > virtualhost.jdbc.JDBCVirtualHostImplWithAccessChecking named 'default'
> > cannot have value 'broker-single-component'. Valid values pattern is:
> > [a-zA-Z_0-9]*
> > at org.apache.qpid.server.model.AbstractConfiguredObject.onValidate(
> > AbstractConfiguredObject.java:1307)
> > at org.apache.qpid.server.virtualhost.AbstractVirtualHost.onValidate(
> > AbstractVirtualHost.java:358)
> > at org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(
> > AbstractConfiguredObject.java:1161)
> > at org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(
> > AbstractConfiguredObject.java:582)
> > at org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(
> > AbstractConfiguredObject.java:571)
> > at org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(
> > AbstractConfiguredObject.java:632)
> > at org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(
> > AbstractConfiguredObject.java:625)
> > at org.apache.qpid.server.configuration.updater.TaskExecutorImpl$
> > TaskLoggingWrapper.execute(TaskExecutorImpl.java:252)
> > at org.apache.qpid.server.configuration.updater.TaskExecutorImpl$
> > CallableWrapper$1.run(TaskExecutorImpl.java:324)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at javax.security.auth.Subject.doAs(Subject.java:360)
> > at org.apache.qpid.server.configuration.updater.TaskExecutorImpl$
> > CallableWrapper.call(TaskExecutorImpl.java:317)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> > 2017-10-16 11:11:02,565 INFO  [Broker-Config] (q.m.b.listening) -
> [Broker]
> > BRK-1002 : Starting : Listening on TCP port 42812
> > 2017-10-16 11:11:02,567 INFO  [Broker-Config] (q.m.m

Re: [Qpid Java Broker 6.1.4] Broker is ready even if an error is occuring on startup and failStartupWithErroredChild set to true

[Adel Boutros]

Hello Rob,

If a virtual host is not available, then all queues and persisted messages are 
currently unavailable and the broker can be considered in a critical state due 
to the messages unavailability.

Is there a way to enforce that a broker will fail to startup unless all of its 
virtual host are started correctly via an option?

Regards,
Adel

From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Monday, October 16, 2017 11:50:34 AM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.1.4] Broker is ready even if an error is 
occuring on startup and failStartupWithErroredChild set to true

Hi Adel,

I think broker.failStartupWithErroredChild=true will only cause the broker
to fail if a *direct* child of the broker fails to start, the vhost is a
child of the vhostnode, so if the vhost node starts up, the broker doesn't
fail.

-- Rob

On 16 October 2017 at 11:16, Adel Boutros <adelbout...@live.com> wrote:

> Hello,
>
>
> Using the Qpid Java Broker 6.1.4, I have noticed that even if i specify
> "set QPID_OPTS=-Dbroker.failStartupWithErroredChild=true" and my JDBC
> virtual host cannot start, then the broker is set to ready.
>
>
> Is this expected?
>
>
> 2017-10-16 11:11:02,520 ERROR [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject)
> - Failed to open object with name 'default'.  Object will be put into ERROR
> state.
> org.apache.qpid.server.configuration.IllegalConfigurationException:
> Attribute 'tableNamePrefix' instance of org.apache.qpid.server.
> virtualhost.jdbc.JDBCVirtualHostImplWithAccessChecking named 'default'
> cannot have value 'broker-single-component'. Valid values pattern is:
> [a-zA-Z_0-9]*
> at org.apache.qpid.server.model.AbstractConfiguredObject.onValidate(
> AbstractConfiguredObject.java:1307)
> at org.apache.qpid.server.virtualhost.AbstractVirtualHost.onValidate(
> AbstractVirtualHost.java:358)
> at org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(
> AbstractConfiguredObject.java:1161)
> at org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(
> AbstractConfiguredObject.java:582)
> at org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(
> AbstractConfiguredObject.java:571)
> at org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(
> AbstractConfiguredObject.java:632)
> at org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(
> AbstractConfiguredObject.java:625)
> at org.apache.qpid.server.configuration.updater.TaskExecutorImpl$
> TaskLoggingWrapper.execute(TaskExecutorImpl.java:252)
> at org.apache.qpid.server.configuration.updater.TaskExecutorImpl$
> CallableWrapper$1.run(TaskExecutorImpl.java:324)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at org.apache.qpid.server.configuration.updater.TaskExecutorImpl$
> CallableWrapper.call(TaskExecutorImpl.java:317)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 2017-10-16 11:11:02,565 INFO  [Broker-Config] (q.m.b.listening) - [Broker]
> BRK-1002 : Starting : Listening on TCP port 42812
> 2017-10-16 11:11:02,567 INFO  [Broker-Config] (q.m.m.startup) - [Broker]
> MNG-1001 : Web Management Startup
> 2017-10-16 11:11:02,704 INFO  [Broker-Config] (q.m.m.listening) - [Broker]
> MNG-1002 : Starting : HTTP : Listening on TCP port 42813
> 2017-10-16 11:11:02,706 INFO  [Broker-Config] (q.m.m.ready) - [Broker]
> MNG-1004 : Web Management Ready
> 2017-10-16 11:11:02,751 INFO  [Broker-Config] (q.m.b.ready) - [Broker]
> BRK-1004 : Qpid Broker Ready
>
>
>
> Regards,
>
> Adel
>

Re: [Qpid Java Broker 6.1.4] Some expections are hidden

[Adel Boutros]

No, this was the only case I hit while testing my use case.


Regards,

ADel


From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Monday, October 16, 2017 12:07:56 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.1.4] Some expections are hidden

To my knowledge this is not deliberate, it's a bug :-) It looks like this
particular case has been this way since at least 2014...

Have you found any other cases?

-- Rob



On 16 October 2017 at 11:22, Adel Boutros <adelbout...@live.com> wrote:

> Hello,
>
>
> While using the Qpid Java Broker, I have noticed that sometimes the causes
> of the exceptions are silenced and thus I don't know why my broker failed.
> I had to remote debug it to find out.
>
> I wanted to know if this was on purpose or not?
>
>
> You can check for example: GenericJDBCMessageStore.java (line 107)
>
>
> Exception shown
>
> --
>
> Failed to create connection provider for connectionUrl:
> jdbc:derby://localhost:10452/sample and username: user
>
>
> Exception after remote debugging
>
> ---
>
> Unable to open a test connection to the given database. JDBC url =
> jdbc:derby://localhost:10452/sample, username = user. Terminating
> connection pool. Original Exception: --
> java.sql.SQLNonTransientConnectionException: Password length (0) is
> outside the range of 1 to 255.
> at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at java.sql.DriverManager.getConnection(DriverManager.java:664)
> at java.sql.DriverManager.getConnection(DriverManager.java:247)
> at com.jolbox.bonecp.BoneCP.obtainRawInternalConnection(BoneCP.java:256)
>
>
> Regards,
>
> Adel
>

[Qpid Java Broker 6.1.4] Some expections are hidden

[Adel Boutros]

Hello,


While using the Qpid Java Broker, I have noticed that sometimes the causes of 
the exceptions are silenced and thus I don't know why my broker failed. I had 
to remote debug it to find out.

I wanted to know if this was on purpose or not?


You can check for example: GenericJDBCMessageStore.java (line 107)


Exception shown

--

Failed to create connection provider for connectionUrl: 
jdbc:derby://localhost:10452/sample and username: user


Exception after remote debugging

---

Unable to open a test connection to the given database. JDBC url = 
jdbc:derby://localhost:10452/sample, username = user. Terminating connection 
pool. Original Exception: --
java.sql.SQLNonTransientConnectionException: Password length (0) is outside the 
range of 1 to 255.
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at com.jolbox.bonecp.BoneCP.obtainRawInternalConnection(BoneCP.java:256)


Regards,

Adel

Re: Consumer affinity (JMSXGroupID), AMQP 1.0

[Adel Boutros]

Thanks!


From: Ken Giusti <kgiu...@redhat.com>
Sent: Friday, September 29, 2017 3:54:20 PM
To: users; keith.w...@gmail.com
Subject: Re: Consumer affinity (JMSXGroupID), AMQP 1.0

At the moment the qpid dispatch router ignores all group related
message properties  when computing the route for a destination.

I've opened a corresponding feature request against the router to
track support for message groups:

https://issues.apache.org/jira/browse/DISPATCH-843

On Fri, Sep 29, 2017 at 9:23 AM, Keith W <keith.w...@gmail.com> wrote:
> A JIRA has been raised for this problem:
>
> https://issues.apache.org/jira/browse/QPID-7937
>
> On 29 September 2017 at 11:47, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
>> On 29 September 2017 at 10:35, Adel Boutros <adelbout...@live.com> wrote:
>>
>>> Hello Rob,
>>>
>>>
>>> I would like to give my opinion on this.
>>>
>>>
>>> In our current use cases, we are configuring the brokers dynamically using
>>> the REST API. We would like to have this possibility in the use case of
>>> Olivier.
>>
>>
>>> Also, having to restart the virtual host is damaging the High Availability
>>> of the messaging system. This is because while the Virtual Host is
>>> restarting, no queues are available and the messages are inaccessible. So I
>>> was wondering if restarting the virtual is a must or it could be fixed in a
>>> Jira story?
>>>
>>>
>>
>> Sorry - my wording wasn't very clear.  If you set this when you first
>> create the queue then you don't need to restart the vhost... however if you
>> have an existing queue that you want to change, then the effect won't be
>> seen until the vhost is restarted (basically the queue sets itself up to be
>> "group aware" or "not group aware" when it starts up, it can't change while
>> it is running).  I don't think this is really an issue for you in that when
>> you create your queues with the REST API you just need to set this
>> attribute.
>>
>>
>>>
>>> Regarding the 2nd point of multiple brokers and dispatch router, if all
>>> brokers have the same queues configured with the appropriate grouping
>>> config, would that really break the feature?
>>>
>>> In our current use cases, all components have the same configuration all
>>> the time (All brokers have same queues and same for the dispatch router).
>>>
>>> So I would imagine if a consumer wants to consume a message with the
>>> correct group, the dispatch router will propagate this header to any
>>> available broker and will only get the corresponding messages.
>>>
>>>
>>>
>> The way grouping works is that the first time a message with a particular
>> group id comes along, the broker will assign that group to a particular
>> consumer.  Each broker will do this independently.  So if you have two
>> brokers B1 and B2; and two consumers C1 and C2  and message M of group A
>> arrives on B1 whereas message N of group A arrives on B2; then B1 may
>> decide to associate group A with C1 whereas broker B2 decides to associate
>> group A with consumer C2.  So message groups with multiple brokers will not
>> work behind a router *unless* the router is enhanced so that it is aware of
>> message grouping (so all messages of the same group are sent to the same
>> broker) or the brokers somehow share information about the group ->
>> consumer assignment.
>>
>> -- Rob
>>
>> What do you think?
>>>
>>>
>>> Regards,
>>>
>>> Adel
>>>
>>> 
>>> From: Rob Godfrey <rob.j.godf...@gmail.com>
>>> Sent: Friday, September 29, 2017 9:14:52 AM
>>> To: users@qpid.apache.org
>>> Subject: Re: Consumer affinity (JMSXGroupID), AMQP 1.0
>>>
>>> On 29 September 2017 at 01:09, Olivier Mallassi <
>>> olivier.malla...@gmail.com>
>>> wrote:
>>>
>>> > Gentleman,
>>> >
>>> > I will need your help.
>>> >
>>> > I have a use case where I would like to guarantee "consumer affinity",
>>> > which is usually implemented using the JMSXGroupID (actually, I am sure
>>> it
>>> > was working w/ AMQP 0.10 clients but here I am using AMQP 1.0)
>>> >
>>> > My test does the "classical" case:
>>> > for (i ... i < 100.)
>>> >   Message textMsg = new TextM
>>> >

Re: Consumer affinity (JMSXGroupID), AMQP 1.0

[Adel Boutros]

Hello Rob,


I would like to give my opinion on this.


In our current use cases, we are configuring the brokers dynamically using the 
REST API. We would like to have this possibility in the use case of Olivier.

Also, having to restart the virtual host is damaging the High Availability of 
the messaging system. This is because while the Virtual Host is restarting, no 
queues are available and the messages are inaccessible. So I was wondering if 
restarting the virtual is a must or it could be fixed in a Jira story?


Regarding the 2nd point of multiple brokers and dispatch router, if all brokers 
have the same queues configured with the appropriate grouping config, would 
that really break the feature?

In our current use cases, all components have the same configuration all the 
time (All brokers have same queues and same for the dispatch router).

So I would imagine if a consumer wants to consume a message with the correct 
group, the dispatch router will propagate this header to any available broker 
and will only get the corresponding messages.


What do you think?


Regards,

Adel


From: Rob Godfrey 
Sent: Friday, September 29, 2017 9:14:52 AM
To: users@qpid.apache.org
Subject: Re: Consumer affinity (JMSXGroupID), AMQP 1.0

On 29 September 2017 at 01:09, Olivier Mallassi 
wrote:

> Gentleman,
>
> I will need your help.
>
> I have a use case where I would like to guarantee "consumer affinity",
> which is usually implemented using the JMSXGroupID (actually, I am sure it
> was working w/ AMQP 0.10 clients but here I am using AMQP 1.0)
>
> My test does the "classical" case:
> for (i ... i < 100.)
>   Message textMsg = new TextM
>textMsg.setStringProperty("JMSXGroupID", "groupA")
>   MessageProducer.send(textMsg);
>
> and I start two consumers (assuming only one would work).
>
> What I observe is that both consumers are receiving messages, acting as
> competing consumers. I also tried added the qpid.group_header_key property
> to the queue but it does not change anything.
>
>
> My setup is
> - java broker 6.0.4 & 6.1.4
> - java clients using qpid-jms 0.25.0 (AMQP 1.0)
>
> Is this the expected behaviour? Any ideas?
>
>
This is a bug in the AMQP 1.0 behaviour of the broker.  The Message
Grouping functionality was originally built around the AMQP 0-x protocols
and is looking for a message group in the application headers of the
message.  In AMQP 1.0 there is a dedicated property for this and the JMS
client is (correctly from an AMQP 1.0 point of view) placing the group id
there.

As a work around instead of using JMSXGroupID you could use any other (non
JMSX prefixed) header, e.g.:

 textMsg.setStringProperty("qpidBugWorkaround", "groupA")

Note that on the broker you need to configure the queue so it knows which
header to use; this is stored in the messageGroupKey property of the queue
(to "qpidBugWorkaround" in this case) .  Note that after setting this
property you will need to restart the virtual host before the change takes
effect.


>
> Complementary question: let's assume now, that there is the DR between the
> broker & the consumers. Does the DR "propagate" or support "grouping
> messages"? (I assume it is depending if you route the link or messages)
>

With a single broker and link routing, yes grouping messages should
continue to work.

If there are multiple brokers sharding the queue then it would not work -
to support this the router would need to be changed to recognize grouping
and send all messages with the same group id to the same broker waypoint
(also, in this case, you would need to use message routing for inbound
messages and link routing for consuming messages).  We have talked about
support for behaviour like this before, but there is nothing implemented
yet as far as I know.

-- Rob


>
>
> thanks for your help
>
> Regards.
>

Re: Plans for Qpid Broker J v7.0

[Adel Boutros]

Hello Keith,


Normally, with a major release, I could expect some broken APIs when developing 
code for an older version of the Qpid Broker such as REST API for communicating 
with the broker or any configuration related disruptive changes.


Does the 7.0 version include any disruptive change? Or if I just bump the 
version of my broker to 7.0 (from 6.0), it will work out of the box?


Regards,

Adel


From: Keith W 
Sent: Wednesday, September 27, 2017 9:38:15 AM
To: users@qpid.apache.org
Subject: Plans for Qpid Broker J v7.0

Hi all,

Qpid Broker J (the Java Broker) is stabilising ready for the next
release.   The major user facing changes in this release will be: much
improved AMQP 1.0 support, support for JMS 2.0 clients implementing
the AMQP 1.0 JMS bind mapping, and much improved message conversion to
benefit users with applications using AMQP 1.0 and the older AMQP
protocols.  We hope to be putting out an RC in a few weeks time.

This anyone has any additional needs, please discuss here.

cheers, Keith.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to kill a dead broker

[Adel Boutros]

Sorry Alex :(

From: Robbie Gemmell <robbie.gemm...@gmail.com>
Sent: Tuesday, September 19, 2017 1:48:48 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to kill 
a dead broker

Alex or Oleksandr, rather than Rudyy :)

On 19 September 2017 at 11:22, Adel Boutros <adelbout...@live.com> wrote:
> Hello Rudyy,
>
>
> +1 for the enhancements 
>
>
> Regards,
>
> Adel
>
> 
> From: Oleksandr Rudyy <oru...@gmail.com>
> Sent: Tuesday, September 19, 2017 11:17:15 AM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to 
> kill a dead broker
>
> Hi Olivier,
>
> Rob have already provided comprehensive answers on your questions.
>
> One thing I would like to add is that both REST API and stop script should
> shutdown broker gracefully. The script uses signals: it sends SIGTERM to
> initiate the graceful shutdown. Only if process is still alive after 2
> seconds after sending SIGTERM, the SIGKILL signal is sent. I raised
> QPID-7910 [1] to improve stop script. The possible improvements are listed
> in the JIRA description.
>
> Kind Regards,
> Alex
>
>
> [1] https://issues.apache.org/jira/browse/QPID-7910
>
>
> On 18 September 2017 at 21:53, VERMEULEN Olivier <
> olivier.vermeu...@murex.com> wrote:
>
>> Hello,
>>
>> Following up on Adel's email.
>> I took a look at the initiateShutdown endpoint you mentioned.
>> I tested it and it seems to work but I don't see it in any documentation,
>> not even in the broker apidocs.
>> Is there a reason for that? Is this feature officially supported?
>> And one more question, why is the broker's qpid.stop script not using the
>> same graceful mechanism?
>>
>> Thanks,
>> Olivier
>>
>> -Original Message-
>> From: Adel Boutros [mailto:adelbout...@live.com]
>> Sent: jeudi 14 septembre 2017 18:34
>> To: users@qpid.apache.org
>> Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to
>> kill a dead broker
>>
>> Thank you Rudyy,
>>
>>
>> Unfortunately, I don't have any extra  information to share. May be the
>> stop script should be updated to check output of kill command to confirm
>> the process is still here.
>>
>>
>> Regards,
>>
>> Adel
>>
>> 
>> From: Oleksandr Rudyy <oru...@gmail.com>
>> Sent: Friday, September 8, 2017 1:46:54 PM
>> To: users@qpid.apache.org
>> Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to
>> kill a dead broker
>>
>> Hi Adel,
>> Thanks for reporting the issue. The qpid.stop script might need more love,
>> though, after sending SIGTERM or SIGKILL event to the broker process, it
>> waits for 1 second and than verifies that process with given PID is still
>> reported by ps (ps -e | grep $1 | wc -l). If process is not reported, no
>> further attempts to send termination signal is made. It seems that in your
>> case the Broker process was present in process table. I could be that it
>> became defunctional. You mentioned that it happens randomly. Do you know
>> what what happens with the broker and broker jvm? Is broker shutdown
>> gracefully? If not, it could be an indication of issue with broker shutdown
>> or jvm exit.
>>
>> Additionally, I would like to point out that you can call Broker REST API
>> to shutdown the broker (/api/latest/broker/initiateShutdown). As
>> operation name suggests, it does not shutdown broker immediately but rather
>> starts the broker  shutdown process and exits. If broker restart is
>> required, a restart operation can be invoked via REST API as well
>> (/api/latest/broker/restart).
>>
>> Kind Regards,
>> Alex
>>
>>
>> On 6 September 2017 at 17:21, Adel Boutros <adelbout...@live.com> wrote:
>>
>> > Hello,
>> >
>> >
>> > In one of our tests, we were having a random failure. It seems we
>> > cannot stop a broker correctly.
>> >
>> > We have a started broker and we call "bin/qpid.stop $BROKER_PID" to
>> > stop it. It seems to work from the first time but maybe not fast
>> > enough because the script keeps trying to kill the broker which is
>> actually dead.
>> >
>> >
>> > Is this a know issue? Is it fixed on a newer version?
>> >
>> >
>> > Command output
>> >
>> > ===
>> >
>> >

Re: Plans for the Qpid Dispatch Router 1.0.0

[Adel Boutros]

Hello Ted,


A nice early Christmas gift for me would be 
https://issues.apache.org/jira/browse/DISPATCH-773 (You don't have to be that 
generous though if it is not possible).


Regards,

Adel


From: Ted Ross 
Sent: Monday, September 18, 2017 10:08:18 PM
To: users@qpid.apache.org
Subject: Plans for the Qpid Dispatch Router 1.0.0

Folks,

We have a good slate of resolved or almost-resolved issues for the next
Dispatch Router release.  I would like to put out a release candidate at
the end of the month.  If anyone has any needs or priorities for this
release, please discuss on this thread.

Regards,
-Ted

Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to kill a dead broker

[Adel Boutros]

Hello Rudyy,


+1 for the enhancements 


Regards,

Adel


From: Oleksandr Rudyy <oru...@gmail.com>
Sent: Tuesday, September 19, 2017 11:17:15 AM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to kill 
a dead broker

Hi Olivier,

Rob have already provided comprehensive answers on your questions.

One thing I would like to add is that both REST API and stop script should
shutdown broker gracefully. The script uses signals: it sends SIGTERM to
initiate the graceful shutdown. Only if process is still alive after 2
seconds after sending SIGTERM, the SIGKILL signal is sent. I raised
QPID-7910 [1] to improve stop script. The possible improvements are listed
in the JIRA description.

Kind Regards,
Alex


[1] https://issues.apache.org/jira/browse/QPID-7910


On 18 September 2017 at 21:53, VERMEULEN Olivier <
olivier.vermeu...@murex.com> wrote:

> Hello,
>
> Following up on Adel's email.
> I took a look at the initiateShutdown endpoint you mentioned.
> I tested it and it seems to work but I don't see it in any documentation,
> not even in the broker apidocs.
> Is there a reason for that? Is this feature officially supported?
> And one more question, why is the broker's qpid.stop script not using the
> same graceful mechanism?
>
> Thanks,
> Olivier
>
> -Original Message-
> From: Adel Boutros [mailto:adelbout...@live.com]
> Sent: jeudi 14 septembre 2017 18:34
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to
> kill a dead broker
>
> Thank you Rudyy,
>
>
> Unfortunately, I don't have any extra  information to share. May be the
> stop script should be updated to check output of kill command to confirm
> the process is still here.
>
>
> Regards,
>
> Adel
>
> 
> From: Oleksandr Rudyy <oru...@gmail.com>
> Sent: Friday, September 8, 2017 1:46:54 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to
> kill a dead broker
>
> Hi Adel,
> Thanks for reporting the issue. The qpid.stop script might need more love,
> though, after sending SIGTERM or SIGKILL event to the broker process, it
> waits for 1 second and than verifies that process with given PID is still
> reported by ps (ps -e | grep $1 | wc -l). If process is not reported, no
> further attempts to send termination signal is made. It seems that in your
> case the Broker process was present in process table. I could be that it
> became defunctional. You mentioned that it happens randomly. Do you know
> what what happens with the broker and broker jvm? Is broker shutdown
> gracefully? If not, it could be an indication of issue with broker shutdown
> or jvm exit.
>
> Additionally, I would like to point out that you can call Broker REST API
> to shutdown the broker (/api/latest/broker/initiateShutdown). As
> operation name suggests, it does not shutdown broker immediately but rather
> starts the broker  shutdown process and exits. If broker restart is
> required, a restart operation can be invoked via REST API as well
> (/api/latest/broker/restart).
>
> Kind Regards,
> Alex
>
>
> On 6 September 2017 at 17:21, Adel Boutros <adelbout...@live.com> wrote:
>
> > Hello,
> >
> >
> > In one of our tests, we were having a random failure. It seems we
> > cannot stop a broker correctly.
> >
> > We have a started broker and we call "bin/qpid.stop $BROKER_PID" to
> > stop it. It seems to work from the first time but maybe not fast
> > enough because the script keeps trying to kill the broker which is
> actually dead.
> >
> >
> > Is this a know issue? Is it fixed on a newer version?
> >
> >
> > Command output
> >
> > ===
> >
> > Waiting 1 second for 514 to exit
> > broker/bin/qpid.stop: line 49: kill: (514) - No such process Waiting 1
> > second for 514 to exit
> > broker/bin/qpid.stop: line 41: kill: (514) - No such process Waiting 1
> > second for 514 to exit
> > broker/bin/qpid.stop: line 41: kill: (514) - No such process Waiting 1
> > second for 514 to exit Stopped trying to kill process: 514 Attempted
> > to stop 2 times
> >
> >
> ***
>
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not
> the intended recipient you are not authorised to distribute, copy or use
> this e-mail or any attachment to it. Murex cannot guarantee that it is
> virus free and accepts no responsibility for any loss or damage arising
> from its use. If you have received this e-mail in error please notify
> immediately the sender and delete the original email received, any
> attachments and all copies from your system.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Does qpid-client-6.0.4 support AMQP 1.0 ?

[Adel Boutros]

Hello,


I agree the website page you reference to seems confusing especially that the 
client mentions Qpid JMS. From my experience, I confirm the Qpid clients (at 
least JMS) supports AMQP 1.0.

We use it exclusively in 1.0 mode along with the Qpid Java Broker 6.0.4 (also 
only in AMQP 1.0) and it is working.


Regards,

Adel


From: Ayed, Saoussen 
Sent: Friday, September 15, 2017 12:13:33 PM
To: users@qpid.apache.org
Subject: Does qpid-client-6.0.4 support AMQP 1.0 ?

Hi Apache Team,

Could you please provide us information if qpid-client-6.0.4 supports AMQP 1.0 ?

I know that it’s not mentioned on your official site at link : 
https://qpid.apache.org/releases/qpid-java-6.0.4/index.html
But we were surprised that one of the exchanges has decommissioned old AMQP 
versions and now only supports AMQP 1.0 (this had been confirmed it’s done by 
exchange) and we are still able to connect to exchange queues.

We would much appreciate your help on this topics as it will help us understand 
what’s currently happening.

Kind Regards,

Saoussen Ayed
Business Analyst
Post-Trade Derivatives & Securites
T:  +216 70 10 66 00 (ext: 2166287)
E: saoussen.a...@fisglobal.com
FIS | Empowering the Financial World [cid:image005.png@01D11265.2C7F1D60] 
 [cid:image006.png@01D11265.2C7F1D60] 
 [cid:image007.png@01D11265.2C7F1D60] 


[cid:image004.jpg@01D2A278.DB978040]

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.

Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to kill a dead broker

[Adel Boutros]

Thank you Rudyy,


Unfortunately, I don't have any extra  information to share. May be the stop 
script should be updated to check output of kill command to confirm the process 
is still here.


Regards,

Adel


From: Oleksandr Rudyy <oru...@gmail.com>
Sent: Friday, September 8, 2017 1:46:54 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to kill 
a dead broker

Hi Adel,
Thanks for reporting the issue. The qpid.stop script might need more love,
though, after sending SIGTERM or SIGKILL event to the broker process, it
waits for 1 second and than verifies that process with given PID is still
reported by ps (ps -e | grep $1 | wc -l). If process is not reported, no
further attempts to send termination signal is made. It seems that in your
case the Broker process was present in process table. I could be that it
became defunctional. You mentioned that it happens randomly. Do you know
what what happens with the broker and broker jvm? Is broker shutdown
gracefully? If not, it could be an indication of issue with broker shutdown
or jvm exit.

Additionally, I would like to point out that you can call Broker REST API
to shutdown the broker (/api/latest/broker/initiateShutdown). As operation
name suggests, it does not shutdown broker immediately but rather starts
the broker  shutdown process and exits. If broker restart is required, a
restart operation can be invoked via REST API as well
(/api/latest/broker/restart).

Kind Regards,
Alex


On 6 September 2017 at 17:21, Adel Boutros <adelbout...@live.com> wrote:

> Hello,
>
>
> In one of our tests, we were having a random failure. It seems we cannot
> stop a broker correctly.
>
> We have a started broker and we call "bin/qpid.stop $BROKER_PID" to stop
> it. It seems to work from the first time but maybe not fast enough because
> the script keeps trying to kill the broker which is actually dead.
>
>
> Is this a know issue? Is it fixed on a newer version?
>
>
> Command output
>
> ===
>
> Waiting 1 second for 514 to exit
> broker/bin/qpid.stop: line 49: kill: (514) - No such process
> Waiting 1 second for 514 to exit
> broker/bin/qpid.stop: line 41: kill: (514) - No such process
> Waiting 1 second for 514 to exit
> broker/bin/qpid.stop: line 41: kill: (514) - No such process
> Waiting 1 second for 514 to exit
> Stopped trying to kill process: 514
> Attempted to stop 2 times
>
>

[Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to kill a dead broker

[Adel Boutros]

Hello,


In one of our tests, we were having a random failure. It seems we cannot stop a 
broker correctly.

We have a started broker and we call "bin/qpid.stop $BROKER_PID" to stop it. It 
seems to work from the first time but maybe not fast enough because the script 
keeps trying to kill the broker which is actually dead.


Is this a know issue? Is it fixed on a newer version?


Command output

===

Waiting 1 second for 514 to exit
broker/bin/qpid.stop: line 49: kill: (514) - No such process
Waiting 1 second for 514 to exit
broker/bin/qpid.stop: line 41: kill: (514) - No such process
Waiting 1 second for 514 to exit
broker/bin/qpid.stop: line 41: kill: (514) - No such process
Waiting 1 second for 514 to exit
Stopped trying to kill process: 514
Attempted to stop 2 times

Re: Welcome Adel Boutros as an Apache Qpid committer

[Adel Boutros]

Thank you all! It has been a fun and exciting journey so far :)


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Wednesday, August 9, 2017 3:13:31 PM
To: users@qpid.apache.org
Subject: Re: Welcome Adel Boutros as an Apache Qpid committer

Adel, congrats and welcome. Looking forward to your many valuable
contributions. Thanks.

On Wed, Aug 9, 2017 at 6:49 AM, Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:

> The Qpid PMC have voted to grant commit rights to Adel Boutros in
> recognition of continued contributions to the project.
>
> Welcome, Adel!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Proton 0.16.0] [Dispatch Router 0.7.0] [Java Broker 6.0.4] [JMS 0.11.1] JMS sender's connection is being closed by the dispatch router

[Adel Boutros]

Hello Ganesh,

Unfortunately no, the jira issue you are mentioning is about dispatch 0.8.0 
whereas here we are talking about dispatch 0.7.0.
We tried compiling the 0.8 version with gcc4.9.2 but still had test failures.

From: Ganesh Murthy <gmur...@redhat.com>
Sent: Thursday, August 3, 2017 10:32:25 PM
To: users@qpid.apache.org
Subject: Re: [Proton 0.16.0] [Dispatch Router 0.7.0] [Java Broker 6.0.4] [JMS 
0.11.1] JMS sender's connection is being closed by the dispatch router

On Wed, Aug 2, 2017 at 12:42 PM, Adel Boutros <adelbout...@live.com> wrote:

> Hello,
>
>
> As stated in a separate email, we are trying to compile Proton/Dispatch
> router on Solaris using GCC4.9.2. The code compiles fine and all the unit
> tests are green.
>
>
> Hi Adel,
 If the code compiles and all the unit tests are green on Solaris, can
this JIRA be marked as resolved ?
https://issues.apache.org/jira/browse/DISPATCH-738
Thanks.

> However, we have noticed a weird failure in our of our feature tests. The
> test is composed of a JMS producer (0.11.1) connected to a dispatch router
> which is backed by 2 Qpid Java Broker (6.0.4).
>
> The sender is sending around 500 messages in asynchronous mode (
> jms.forceAsyncSend=true).
>
> It seems that while the JMS producer is sending the message, at some
> random stage, the connection is dropped. The error seems to be coming from
> Proton which seems to be used by the Dispatch Router for AMQP connections
> if I am not mistaken.
>
>
> I have attached the logs of the Producer(Logging in debug mode on
> org.apache.qpid) and Dispatch Router (Log level set to Trace +
> PN_TRACE_FRM=1 + PN_TRACE_RAW=1)
>
>
> Could you please provide us hints or help to analyze this problem?
>
>
> Regards,
>
> Adel
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

[Proton-c C++ 0.16.0] [Solaris Sparc] [GCC 4.9.2] Assuming threads will propage exceptions

[Adel Boutros]

Hello,


I hope you missed my mails about Solaris 


We are currently testing whether we can compile on Solaris using GCC 4.9.2. We 
were successful in doing so for Solaris x86 but we have hit a problem in Sparc.


It seems related to certain assumptions made around how threads propagates 
exceptions:


The failing test is "examples/cpp/example_test.py: test_ssl_bad_name"

In examples/cpp/ssl.cpp [1], it spawns another thread and wait for it to throw 
an exception.


However, if you check the thread documentation[2], it states the propagation of 
exceptions is not guaranteed[3].


So I was wondering if the assumption that Proton makes is not a big dangerous 
and should be changed?


Simpler Example

-
#include 
#include 
#include 

class example_cert_error : public std::runtime_error
{
public:
explicit example_cert_error(const std::string& s) : 
std::runtime_error(s) {}
};

int main(int argc, char** argv) {
try {
std::thread th([](){throw example_cert_error("my error"); });
} catch (const example_cert_error& ce) {
std::cout << "Caught: " << ce.what() << std::endl;
}
return 0;
}



Solaris X86

---
$ g++49 -std=c++11 throw.cpp -o throw
$ ./throw
Caught: my error

Solaris Sparc
-
$ g++49 -std=c++11 throw.cpp -o throw
$ ./throw
terminate called without an active exception
Abort (core dumped)


[1]: https://github.com/apache/qpid-proton/blob/0.16.x/examples/cpp/ssl.cpp#L178

[2]: http://en.cppreference.com/w/cpp/thread/thread

[3]: The top-level function may communicate its return value or an exception to 
the caller

Re: Reactor receiver stuck when transport is broken

[Adel Boutros]

Hello,


I imagine you are talking about Qpid Proton's reactor?

If that is the case, have you implemented the "onError" as well? Some errors go 
there.

Also, the reactor will always be running until you close the connection in one 
of the callbacks; are you doing so?

void on_transport_error(proton::transport ) {
t.connection().close();
}


Regards,
Adel


From: Garlapati Sreeram Kumar 
Sent: Friday, July 14, 2017 6:39 PM
To: users@qpid.apache.org
Subject: RE: Reactor receiver stuck when transport is broken

Hello Folks!

Any help is much appreciated….

Sent from Mail for Windows 10
[http://www.microsoft.com/en-us/outlook-com/img/Outlook_Facebook_Icon-2927f4df28.jpg]

Check out Outlook.com – free, personal email from 
Microsoft.
go.microsoft.com
Find the right Outlook for you. Get the optimum email experience across all 
your devices




From: Garlapati Sreeram Kumar
Sent: Monday, July 10, 2017 5:09 PM
To: users@qpid.apache.org 
Subject: Reactor receiver stuck when transport is broken

Hello folks!

We have a client with 1 Connection with 1 ReceiveLink running in 1 Thread where 
it prints when ever onDelivery() handler is invoked.
Receiver sends flow for every 100 messages and Connection IdleTimeout on the 
Service is 4 mins.

In some cases where there are transport issues – we noticed that neither 
onDelivery(event) nor onTransportError() are raised.
The receiver is stuck forever. Even the idleTimeout empty frame is logged as 
written but, it is not detecting that the transport is broken. When we 
workarounded this stuck receiver with creating another brand-new receiveLink on 
the same Connection – we then see onTransportError() event.
Is anyone experiencing this issue? Do, I have to actually listen for any other 
Transport events? Help is much appreciated…

Thanks a lot for your Time!
Sreeram

Sent from Mail for Windows 10

Re: Qpid High Availability

[Adel Boutros]

Once in the past, we tested BDB but at the end, we didn't use it because of 
it's licensing.


I remember when we had issues configuring it, we would start all over from a 
clean work directory because the broker would be in an error state and it was 
the only way we knew to fix it. Have you tried that?


Regards,

Adel


From: girish lc <girish...@gmail.com>
Sent: Tuesday, July 11, 2017 12:03:38 PM
To: users@qpid.apache.org
Subject: Re: Qpid High Availability

Hi Adel,

After including the bdb je 5.0.104, I'm still getting the below error, if any 
of you have already configured could you please send me the screen shot.

[Inline image 1]

On Tue, Jul 11, 2017 at 3:03 PM, Adel Boutros 
<adelbout...@live.com<mailto:adelbout...@live.com>> wrote:
Hello,


You can find it on Oracle's website:

http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-098622.html


Regards,

Adel



From: girish lc <girish...@gmail.com<mailto:girish...@gmail.com>>
Sent: Tuesday, July 11, 2017 11:04:31 AM
To: users@qpid.apache.org<mailto:users@qpid.apache.org>
Subject: Re: Qpid High Availability

Hi Alex,

Could you please share me the location from where I can download bdb je
5.0.104, as I'm not able to find.

Many thanks,

On Tue, Jul 11, 2017 at 1:40 PM, Oleksandr Rudyy 
<oru...@gmail.com<mailto:oru...@gmail.com>> wrote:

> Hi Girish,
>
> I tested HA with bdb je 5.0.73 and got the same error. It appears that je
> configuration setting "je.cleaner.adjustUtilization" was introduced in
> versions after 5.0.73. Unfortunately, the setting is hard-coded in the Qpid
> code. In order to resolve the issue you need to upgrade bdb je to 5.0.104.
>
> Kind Regards,
> Alex
>
> On 10 July 2017 at 16:50, girish lc 
> <girish...@gmail.com<mailto:girish...@gmail.com>> wrote:
>
> > Hi Alex,
> >
> > Thank you for the email,
> >
> > I'm using the below version:
> >
> > qpid-java-6.1.4
> > Berkeley DB Java Edition - 5.0.73
> >
> > Please let me know the correct combination.
> >
> > On Mon, Jul 10, 2017 at 6:54 PM, Oleksandr Rudyy 
> > <oru...@gmail.com<mailto:oru...@gmail.com>>
> wrote:
> >
> > > Hi Girish,
> > >
> > > What version of bdb je library are you using?
> > >
> > > 6.x versions of Qpid Broker are based on bdb je version 5.0.104 due to
> > > Oracle license change.
> > >
> > > Master and new 7.x versions of the Broker will be based new bdb je
> > versions
> > > ( 7.3.7 and above), as Oracle started to distribute je with dual
> > licenses -
> > > one of which is Apache license.
> > >
> > > I am guessing that you are trying to start 6.x version of Broker with
> bd
> > je
> > > 7.3.x.  Please, use je version 5.0.104.
> > >
> > > Kind Regards,
> > > Alex
> > >
> > >
> > > On 10 July 2017 at 14:03, Chandrashekar, Girish <
> > gchandrashe...@wabtec.com<mailto:gchandrashe...@wabtec.com>
> > > >
> > > wrote:
> > >
> > > > Hi Team,
> > > >
> > > >
> > > > Could you please help me to setup Qpid High Availability
> functionality.
> > > >
> > > >
> > > > I am referring the below link, but I am not successful to setup; in
> > fact
> > > I
> > > > got the "422 - je.cleaner.adjustUtilization is not a valid BDBJE
> > > > environment parameter" error  and also I had lost the files and
> folders
> > > > present in my C:\ after this error. I tried the same in 2 virtual
> > > machines
> > > > and also in my local machine same result 
> > > >
> > > >
> > > > https://qpid.apache.org/releases/qpid-java-6.1.4/java-
> > > > broker/book/Java-Broker-High-Availability-CreatingGroup.html
> > > >
> > > >
> > > > Can someone let me know the root cause and also please help me to
> setup
> > > > the High Availability functionality.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Girish LC
> > > >
> > > > 09886521716
> > > >
> > > > This email and any attachments are only for use by the intended
> > > > recipient(s) and may contain legally privileged, confidential,
> > > proprietary
> > > > or otherwise private information. Any unauthorized use, reproduction,
> > > > dissemination, distribution or other disclosure of the contents of
> this
> > > > e-mail or its attachments is strictly prohibited. If you have
> received
> > > this
> > > > email in error, please notify the sender immediately and delete the
> > > > original. Neither this information block, the typed name of the
> sender,
> > > nor
> > > > anything else in this message is intended to constitute an electronic
> > > > signature unless a specific statement to the contrary is included in
> > this
> > > > message.
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> > Girish LC
> > #09886521716
> >
>



--
Regards,
Girish LC
#09886521716



--
Regards,
Girish LC
#09886521716

Re: Qpid High Availability

[Adel Boutros]

Hello,


You can find it on Oracle's website:

http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-098622.html


Regards,

Adel



From: girish lc 
Sent: Tuesday, July 11, 2017 11:04:31 AM
To: users@qpid.apache.org
Subject: Re: Qpid High Availability

Hi Alex,

Could you please share me the location from where I can download bdb je
5.0.104, as I'm not able to find.

Many thanks,

On Tue, Jul 11, 2017 at 1:40 PM, Oleksandr Rudyy  wrote:

> Hi Girish,
>
> I tested HA with bdb je 5.0.73 and got the same error. It appears that je
> configuration setting "je.cleaner.adjustUtilization" was introduced in
> versions after 5.0.73. Unfortunately, the setting is hard-coded in the Qpid
> code. In order to resolve the issue you need to upgrade bdb je to 5.0.104.
>
> Kind Regards,
> Alex
>
> On 10 July 2017 at 16:50, girish lc  wrote:
>
> > Hi Alex,
> >
> > Thank you for the email,
> >
> > I'm using the below version:
> >
> > qpid-java-6.1.4
> > Berkeley DB Java Edition - 5.0.73
> >
> > Please let me know the correct combination.
> >
> > On Mon, Jul 10, 2017 at 6:54 PM, Oleksandr Rudyy 
> wrote:
> >
> > > Hi Girish,
> > >
> > > What version of bdb je library are you using?
> > >
> > > 6.x versions of Qpid Broker are based on bdb je version 5.0.104 due to
> > > Oracle license change.
> > >
> > > Master and new 7.x versions of the Broker will be based new bdb je
> > versions
> > > ( 7.3.7 and above), as Oracle started to distribute je with dual
> > licenses -
> > > one of which is Apache license.
> > >
> > > I am guessing that you are trying to start 6.x version of Broker with
> bd
> > je
> > > 7.3.x.  Please, use je version 5.0.104.
> > >
> > > Kind Regards,
> > > Alex
> > >
> > >
> > > On 10 July 2017 at 14:03, Chandrashekar, Girish <
> > gchandrashe...@wabtec.com
> > > >
> > > wrote:
> > >
> > > > Hi Team,
> > > >
> > > >
> > > > Could you please help me to setup Qpid High Availability
> functionality.
> > > >
> > > >
> > > > I am referring the below link, but I am not successful to setup; in
> > fact
> > > I
> > > > got the "422 - je.cleaner.adjustUtilization is not a valid BDBJE
> > > > environment parameter" error  and also I had lost the files and
> folders
> > > > present in my C:\ after this error. I tried the same in 2 virtual
> > > machines
> > > > and also in my local machine same result 
> > > >
> > > >
> > > > https://qpid.apache.org/releases/qpid-java-6.1.4/java-
> > > > broker/book/Java-Broker-High-Availability-CreatingGroup.html
> > > >
> > > >
> > > > Can someone let me know the root cause and also please help me to
> setup
> > > > the High Availability functionality.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Girish LC
> > > >
> > > > 09886521716
> > > >
> > > > This email and any attachments are only for use by the intended
> > > > recipient(s) and may contain legally privileged, confidential,
> > > proprietary
> > > > or otherwise private information. Any unauthorized use, reproduction,
> > > > dissemination, distribution or other disclosure of the contents of
> this
> > > > e-mail or its attachments is strictly prohibited. If you have
> received
> > > this
> > > > email in error, please notify the sender immediately and delete the
> > > > original. Neither this information block, the typed name of the
> sender,
> > > nor
> > > > anything else in this message is intended to constitute an electronic
> > > > signature unless a specific statement to the contrary is included in
> > this
> > > > message.
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> > Girish LC
> > #09886521716
> >
>



--
Regards,
Girish LC
#09886521716

Re: [Dispatch Router] List of connected producers

[Adel Boutros]

Thank you both,


I will try what you suggested.


I was wondering why the phases are actually named "0" and "1" as this a bit 
confusing. Wouldn't a more meaningful string representation be better 
especially for the users?


Adel


From: Gordon Sim 
Sent: Wednesday, July 5, 2017 9:25:06 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] List of connected producers

On 05/07/17 20:01, Ted Ross wrote:
> You can query a list of links (org.apache.qpid.dispatch.router.link) with
> attribute "owningAddr" equal to the addresses of the waypoint (phase 0 for
> producers, phase 1 for consumers).  I believe that the auto-links will also
> be included in this list, but can be identified by the reversal of the
> direction (i.e. phase 0 out-links and phase 1 in-links are not clients).

You can also filter out the autolinks by selecting only those
linkType==endpoint I believe.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

[Dispatch Router] List of connected producers

[Adel Boutros]

Hello,

I was wondering if there was a way to get the list of producers (or clients in 
general) connected to a queue on the dispatch router?

Context: We would like to block the deletion of a waypoint as long as someone 
might be using it.

Regards,
Adel

Get Outlook for Android

Re: help building proton for windows

[Adel Boutros]

Hello Greg,


Could you show an example of the errors?


We were able to compile Proton-c and C++ bindings 0.17.0 on Windows Server 2012 
but we might not all have the same configuration.


Regards,

Adel


From: Greg Oliver 
Sent: Friday, June 23, 2017 1:12:47 AM
To: users@qpid.apache.org
Subject: help building proton for windows

Hi folks,

Trying to build Proton 0.17.0 on Windows 10 and getting a ton of link errors.

Using Visual Studio 2015.

Seems to be something to do with Win32 vs x64, but don't know for sure.

Thoughts?

Thanks,
Greg

Re: [DISCUSSION] Queue Reject Policy Behaviour

[Adel Boutros]

Hello Lorenz,


"A) If an operator wishes this behavior but we actually implement B)"

How will the operator know which messages to delete?

"C)"

I could imagine a client who has an "End of Day" process which is triggered 
at some point of the day. One of its tasks could be to read piled up messages 
and consume them.


PS: I cannot say I have a specific problem with the behavior you are proposing 
but as you asked for discussions, I tried to create one 


Adel


From: Lorenz Quack <quack.lor...@gmail.com>
Sent: Tuesday, June 13, 2017 2:37:29 PM
To: users@qpid.apache.org; lqu...@apache.org
Subject: Re: [DISCUSSION] Queue Reject Policy Behaviour

Hello Adel,

Thanks for your feedback.

You are right that the desired behaviour depends on the context of
your application.  However, I want to avoid adding configuration
options where it is not necessary.  IMHO, the broker-j already suffers
from an abundance of configuration options and I do not want to
exacerbate the problem.

So is the configuration you suggest necessary/useful?  Let me examine
the three options you provided:

  A) If an operator wishes this behaviour but we actually implement B)
 then the operator could still manually/explicitly delete messages
 from the queue until it is within the new limits.

  B) This is still my preferred behaviour.

  C) I have a hard time coming up with an example where this would be
 useful or desirable.  As you pointed out in the beginning of your
 email an application typically regards its messages as critical
 (no message loss acceptable) or as dispensable (message loss
 acceptable).  Choosing to discard messages but using a timeout
 period seems to indicate conflicting goals.  If the messages
 themselves become interesting TTL should be used instead.
 Do you have a use case in mind where this would be useful?

Note that I do not expect this situation to come about very often.
Typically a queue is configured and then left alone.  Changing the
overflow policy and/or the overflow limits on a live queue should be
very rare.

Kind regards,
Lorenz


On Tue, 2017-06-13 at 10:15 +, Adel Boutros wrote:
> Hello Lorenz,
>
>
> In my opinion, it depends on the context and there is no general rule for 
> this.
>
> For example, if your queue has some sensitive data and your producers 
> considers the messages available. So they will never send them back.
>
> If you delete the messages which overflow the queue, you will lose this 
> important information (which could be Bank accounts for example).
>
>
> If on the other hand, your system is capable of overcoming message loss by 
> resending the messages then you have no problem in silently deleting them.
>
>
> So instead of forcing a behavior, I think the choice should be left to the 
> operator when defining the policy (per queue would be even better):
>
> A) He would explicitly choose to silently delete all overflowing messages 
> immediately
>
> B) He would explicitly choose to ignore current overflowing messages
>
> C) He would explicitly define a period after which current overflowing 
> messages would be deleted (A would be a specific implementation of C)
>
>
> Regards,
>
> Adel
>
> 
> From: Lorenz Quack <quack.lor...@gmail.com>
> Sent: Tuesday, June 13, 2017 11:22:31 AM
> To: Qpid Users
> Subject: Re: [DISCUSSION] Queue Reject Policy Behaviour
>
> Hello,
>
> I personally would expect behaviour B).
>
> As an application I would expect a REJECT policy I either accept or
> reject a message I send.  Silently "rejecting" it retrospectively
> seems counter-intuitive to me.
>
> On the other hand, behaviour A) would bring it more in line with some of
> the other overflow policies that immediately react to a change in the
> limits.
> That being said I would still vote for behaviour A).
>
> Kind regards,
> Lorenz
>
>
> On Tue, 2017-06-13 at 10:21 +0100, Lorenz Quack wrote:
> >
> > Hello all,
> >
> > QPID-7815 [1] proposes the addition of a Queue Overflow Reject Policy
> > to the Qpid broker-j (aka Qpid Broker for Java) component.
> >
> > Queue's allow to define overflow limits (in term of number of messages
> > and/or cumulative size of the messages).  If the limit is breached the
> > overflow policy determines the behaviour.  There are three ways the
> > limits can be breached.
> >
> >   1) A new message arrives at the queue pushing it over the limit.
> >
> >   2) An operator lowers the limit so that existing messages are in
> >  breach of the limit.
> >
> >   3) An operator changes the policy.  For example from a No-op policy
&

Re: Dispatch router 2-phase start

[Adel Boutros]

Hello Ganesh,


Done: https://issues.apache.org/jira/browse/DISPATCH-773


Indeed, I didn't see it could happen even to static config files.


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Monday, May 15, 2017 4:09:17 PM
To: users@qpid.apache.org
Subject: Re: Dispatch router 2-phase start

Hi Adel,
   Can you please enter an enhancement JIRA for this so we can track this. This 
problem definitely needs to be addressed. I see this problem happening even in 
the case of static config files.
If you see here - 
https://github.com/apache/qpid-dispatch/blob/master/python/qpid_dispatch_internal/management/config.py#L167
 - the listener is configured before the waypoint and address entities and 
there is a possibility that a producer and consumer might start directly 
exchanging messages if the listeners are setup are setup and the clients attach 
immediately thereafter and before the router could run thru the rest of the 
static configuration.

Thanks.

- Original Message -
> From: "Jiri Danek" <jda...@redhat.com>
> To: "users" <users@qpid.apache.org>
> Sent: Monday, May 15, 2017 6:21:01 AM
> Subject: Re: Dispatch router 2-phase start
>
> On Mon, May 15, 2017 at 12:14 PM, Adel Boutros <adelbout...@live.com> wrote:
>
> > Indeed, but I would not need an extra port in this case.
> >
> > Also, the extra management port could be used by mistake by any
> > misconfigured consumer/producer.
> >
>
> You could setup a policy to allow only management on this extra port...
>
>
> >
> > 
> > From: Jiri Danek <jda...@redhat.com>
> > Sent: Monday, May 15, 2017 12:04:50 PM
> > To: users
> > Subject: Re: Dispatch router 2-phase start
> >
> > On Mon, May 15, 2017 at 12:00 PM, Adel Boutros <adelbout...@live.com>
> > wrote:
> >
> > > Hello Gordon,
> > >
> > >
> > > With what you are proposing, the order of the configuration becomes
> > > critical because if the public listener is configured before the
> > connectors
> > > and autolinks, I would have the same issue with the producer/consumer. So
> > > my management process would have to send the management commands in a
> > > predefined order.
> > >
> > >
> > > In the case of the 2-phase start, the order of configuration is
> > irrelevant
> > > and the management is thus easier.
> > >
> > >
> > > Regards,
> > >
> > > Adel
> > >
> >
> > On Sat, May 13, 2017 at 11:29 AM, Adel Boutros <adelbout...@live.com>
> > wrote:
> >
> > > Once all dynamic configuration is done, we send a management message to
> > > allow the router to start accepting connections.
> >
> >
> > So even with the 2-phase startup you'd have to keep the order of commands
> > in mind. You'd have to send this special startup command last.
> > --
> > Jiří Daněk
> > Messaging QA
> >
>
>
>
> --
> Jiří Daněk
> Messaging QA
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Dispatch router 2-phase start

[Adel Boutros]

Hello Gordon,


With what you are proposing, the order of the configuration becomes critical 
because if the public listener is configured before the connectors and 
autolinks, I would have the same issue with the producer/consumer. So my 
management process would have to send the management commands in a predefined 
order.


In the case of the 2-phase start, the order of configuration is irrelevant and 
the management is thus easier.


Regards,

Adel


From: Gordon Sim <g...@redhat.com>
Sent: Monday, May 15, 2017 9:58:50 AM
To: users@qpid.apache.org
Subject: Re: Dispatch router 2-phase start

On 13/05/17 10:29, Adel Boutros wrote:
> Hello,
>
> We have noticed a race conditon with the dispatch router's behavior.
> If you have a producer and a consumer exchanging messages on a queue 
> configured on a broker and accessible via the router. The consumer and 
> producers are JMS clients configured with Failover options for retry.
> If the router goes down, the retry mechanism will kick in until it is up 
> again.
>
> As we are configuring th addresses and connectors on the router dynamically, 
> the producer and consumer might connect to the router before the waypointed 
> address is created on it. In this case, a local address will be created on 
> the router. The clients would exchange the messages directly from the router 
> and the messages on the broker would never be consumed.
>
> I discussed this issue with Justin and Ulf during the RivieraDev conference 
> and we were wondering if it was possible to implement a 2-phase startup on 
> the router to avoid this issue.
> In that case, the router would start but not accept any connetion except for 
> management. Once all dynamic configuration is done, we send a management 
> message to allow the router to start accepting connections.
>
> Any thoughts on this?

You could do something similar already by defining a specific listener
for management only in the static config, and then only define the
'public' listener for real clients once any other configuration has been
done.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Dispatch router 2-phase start

[Adel Boutros]

Hello,

We have noticed a race conditon with the dispatch router's behavior.
If you have a producer and a consumer exchanging messages on a queue configured 
on a broker and accessible via the router. The consumer and producers are JMS 
clients configured with Failover options for retry.
If the router goes down, the retry mechanism will kick in until it is up again.

As we are configuring th addresses and connectors on the router dynamically, 
the producer and consumer might connect to the router before the waypointed 
address is created on it. In this case, a local address will be created on the 
router. The clients would exchange the messages directly from the router and 
the messages on the broker would never be consumed.

I discussed this issue with Justin and Ulf during the RivieraDev conference and 
we were wondering if it was possible to implement a 2-phase startup on the 
router to avoid this issue.
In that case, the router would start but not accept any connetion except for 
management. Once all dynamic configuration is done, we send a management 
message to allow the router to start accepting connections.

Any thoughts on this?

Regards,
Adel

Get Outlook for Android

Public CI

[Adel Boutros]

Hello,


We are currently compiling internally Qpid components using Jenkins on Windows, 
Linux and Solaris. In order to ease the process, I was experimenting with 
public CIs and have noticed you are using Travis (For Linux) and Appveyor (For 
Windows).


So I was wondering if you could share your experience regarding the public CI:

   - How do you debug/fix a failing build?

   - Do you just check the logs outputed or do you access the machines 
themselves?

   - Any drawbacks to this approach?

   - Any other info to share?


I was also wondering if you could provide me some tips on how I can do it for 
the other OSes such as Solaris. We have internal VMs but would like to protect 
them from security breaches and abuses. Should we use them or rely on cloud 
infrastructure for example?


Regards,

Adel

Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

[Adel Boutros]

Hello Ganesh,


I have applied your patch and it works as expected.


Regarding Solaris, do you need extra information for analyzing?


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Tuesday, April 4, 2017 1:48:07 PM
To: users@qpid.apache.org
Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

Hi Adel,
I sent out an email to you before I saw our own Travis build indicated that 
it failed the same tests that you were seeing. I apologize. This pull request - 
https://github.com/apache/qpid-dispatch/pull/158/files - should work for you on 
RHEL 6.4. This PR passes on Travis as well as seen here -

https://travis-ci.org/apache/qpid-dispatch/builds/218223226

Thanks.

- Original Message -
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Monday, April 3, 2017 12:57:37 PM
> Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
> Hello Ganesh,
>
>
> Your pull request fixed one of the 3 failing tests
> (system_tests_protocol_family). The others still have the same errors:
>
> 12 - router_policy_test (Failed)
> 18 - system_tests_policy (Failed)
>
>
> Regards,
>
> Adel
>
> 
> From: Ganesh Murthy <gmur...@redhat.com>
> Sent: Monday, April 3, 2017 6:02:31 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
> Hi Adel,
> I believe this pull request -
> https://github.com/apache/qpid-dispatch/pull/157 - must fix the test
> failures you are seeing on RHEL 6.4. Can you please try applying it?
>
> As for the Solaris test failures, there seem to be a whole bunch of them. I
> have created a JIRA - https://issues.apache.org/jira/browse/DISPATCH-738
>
> I am not sure we can get to them before the 0.8.0 release.
>
> Thanks.
>
> - Original Message -
> > From: "Adel Boutros" <adelbout...@live.com>
> > To: users@qpid.apache.org
> > Sent: Friday, March 31, 2017 3:55:32 AM
> > Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
> >
> >
> >
> > Hello Ganesh,
> >
> >
> >
> >
> > Please find attached the 3 build logs of the dispatch router 0.8.0 on Linux
> > (Red Hat 6.4), Solaris x86 and Solaris Sparc.
> >
> > Please note we are using Proton 0.16.0 with only C++ bindings activated.
> >
> >
> >
> >
> > PS: The good news is the code compiles on all 3 OSes but it's the tests
> > which
> > are failing. We consider this as a big step forward compared to the
> > previous
> > versions where the code didn't even compile on Solaris.
> >
> >
> >
> >
> > Regards,
> >
> > Adel
> >
> > From: Ganesh Murthy <gmur...@redhat.com>
> > Sent: Thursday, March 30, 2017 3:10:00 PM
> > To: users@qpid.apache.org
> > Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
> >
> >
> > - Original Message -
> > > From: "Adel Boutros" <adelbout...@live.com>
> > > To: users@qpid.apache.org
> > > Sent: Thursday, March 30, 2017 9:04:01 AM
> > > Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
> > >
> > > I rechecked quickly and I have different behaviors on different OSes.
> > >
> > >
> > > * Linux :
> > >
> > Can you please let us know what Linux flavor you are using so we can try
> > locally?
> > > router_policy_test and system_tests_protocol_family failing as stated
> > > previously
> > >
> > Please also send the complete output of the failing tests.
> > >
> > > *Solaris:
> > >
> > > Only router_policy_test is failing.
> > >
> > > For system_tests_protocol_family, I have the message "Skipping test..IPV6
> > > not
> > > enabled"
> > >
> > >
> > > We have some other test failures on Solaris and Linux but we will need to
> > > debug them and we won't have time at the moment for them. I can send you
> > > a
> > > report with the failures if you wish.
> > >
> > This is the commit that fixed DISPATCH-216 on master -
> > https://github.com/apache/qpid-dispatch/commit/0a60abbf6b06048e1ac7a71a48da82145fa77036
> > I verified that the above commit is present in the Qpid Dispatch Router
> > 0.8.0
> > Release Candidate 1 qpid-dispatch-0.8.0.tar.gz
> > >
> > > Regards,
> > >
> > > Adel
> > >
> > > 
> > > From: Ted Ross <t

Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

[Adel Boutros]

Hello Ganesh,


Your pull request fixed one of the 3 failing tests 
(system_tests_protocol_family). The others still have the same errors:

12 - router_policy_test (Failed)
18 - system_tests_policy (Failed)


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Monday, April 3, 2017 6:02:31 PM
To: users@qpid.apache.org
Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

Hi Adel,
I believe this pull request - 
https://github.com/apache/qpid-dispatch/pull/157 - must fix the test failures 
you are seeing on RHEL 6.4. Can you please try applying it?

As for the Solaris test failures, there seem to be a whole bunch of them. I 
have created a JIRA - https://issues.apache.org/jira/browse/DISPATCH-738

I am not sure we can get to them before the 0.8.0 release.

Thanks.

- Original Message -
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Friday, March 31, 2017 3:55:32 AM
> Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
>
>
> Hello Ganesh,
>
>
>
>
> Please find attached the 3 build logs of the dispatch router 0.8.0 on Linux
> (Red Hat 6.4), Solaris x86 and Solaris Sparc.
>
> Please note we are using Proton 0.16.0 with only C++ bindings activated.
>
>
>
>
> PS: The good news is the code compiles on all 3 OSes but it's the tests which
> are failing. We consider this as a big step forward compared to the previous
> versions where the code didn't even compile on Solaris.
>
>
>
>
> Regards,
>
> Adel
>
> From: Ganesh Murthy <gmur...@redhat.com>
> Sent: Thursday, March 30, 2017 3:10:00 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
>
> - Original Message -
> > From: "Adel Boutros" <adelbout...@live.com>
> > To: users@qpid.apache.org
> > Sent: Thursday, March 30, 2017 9:04:01 AM
> > Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
> >
> > I rechecked quickly and I have different behaviors on different OSes.
> >
> >
> > * Linux :
> >
> Can you please let us know what Linux flavor you are using so we can try
> locally?
> > router_policy_test and system_tests_protocol_family failing as stated
> > previously
> >
> Please also send the complete output of the failing tests.
> >
> > *Solaris:
> >
> > Only router_policy_test is failing.
> >
> > For system_tests_protocol_family, I have the message "Skipping test..IPV6
> > not
> > enabled"
> >
> >
> > We have some other test failures on Solaris and Linux but we will need to
> > debug them and we won't have time at the moment for them. I can send you a
> > report with the failures if you wish.
> >
> This is the commit that fixed DISPATCH-216 on master -
> https://github.com/apache/qpid-dispatch/commit/0a60abbf6b06048e1ac7a71a48da82145fa77036
> I verified that the above commit is present in the Qpid Dispatch Router 0.8.0
> Release Candidate 1 qpid-dispatch-0.8.0.tar.gz
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Ted Ross <tr...@redhat.com>
> > Sent: Thursday, March 30, 2017 2:48:10 PM
> > To: users@qpid.apache.org
> > Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
> >
> > Adel,
> >
> > The commits associated with that Jira and PR #140 are included in this
> > release candidate. We'll need to investigate whether it regressed again
> > or if the commit didn't fix the problem.
> >
> > -Ted
> >
> > On 03/30/2017 11:30 AM, Adel Boutros wrote:
> > > Hello Ted,
> > >
> > >
> > > I thought the 0.8.0 release included the fixes to ignore IPv6 tests but
> > > it
> > > doens't seem to be the case. Ganesh was working on fixing those.
> > >
> > > Do you confirm they are not included?
> > > (
> > > http://qpid.2158936.n2.nabble.com/Fwd-GitHub-qpid-dispatch-pull-request-140-DISPATCH-216-Added-code-to-skip-system-te-td7658538.html#a7658571
> > > )
> > >
> > >
> > > I launched the CI on the release candidate and got the same IPv6 failures
> > > as before
> > >
> > >
> > > The following tests FAILED with ipv6 errors:
> > > 12 - router_policy_test (Failed)
> > > 19 - system_tests_protocol_family (Failed)
> > >
> > >
> > >
> > > 12: Test command: /python278/bin/python
> > > "/dispatch-workspace/build-dir/qpid-dispatch/tests/run.py" "-m"
> > > "

Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

[Adel Boutros]

Small correction:


We are using Proton 0.16.0 with only C++ and Python bindings activated.


From: Adel Boutros
Sent: Friday, March 31, 2017 9:55:32 AM
To: users@qpid.apache.org
Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1


Hello Ganesh,


Please find attached the 3 build logs of the dispatch router 0.8.0 on Linux 
(Red Hat 6.4), Solaris x86 and Solaris Sparc.

Please note we are using Proton 0.16.0 with only C++ bindings activated.


PS: The good news is the code compiles on all 3 OSes but it's the tests which 
are failing. We consider this as a big step forward compared to the previous 
versions where the code didn't even compile on Solaris.


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Thursday, March 30, 2017 3:10:00 PM
To: users@qpid.apache.org
Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1



- Original Message -
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Thursday, March 30, 2017 9:04:01 AM
> Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
> I rechecked quickly and I have different behaviors on different OSes.
>
>
> * Linux :
>
Can you please let us know what Linux flavor you are using so we can try 
locally?
> router_policy_test and system_tests_protocol_family failing as stated
> previously
>
Please also send the complete output of the failing tests.
>
> *Solaris:
>
> Only router_policy_test  is failing.
>
> For system_tests_protocol_family, I have the message "Skipping test..IPV6 not
> enabled"
>
>
> We have some other test failures on Solaris and Linux but we will need to
> debug them and we won't have time at the moment for them. I can send you a
> report with the failures if you wish.
>
This is the commit that fixed DISPATCH-216 on master - 
https://github.com/apache/qpid-dispatch/commit/0a60abbf6b06048e1ac7a71a48da82145fa77036
I verified that the above commit is present in the Qpid Dispatch Router 0.8.0 
Release Candidate 1 qpid-dispatch-0.8.0.tar.gz
>
> Regards,
>
> Adel
>
> 
> From: Ted Ross <tr...@redhat.com>
> Sent: Thursday, March 30, 2017 2:48:10 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
> Adel,
>
> The commits associated with that Jira and PR #140 are included in this
> release candidate.  We'll need to investigate whether it regressed again
> or if the commit didn't fix the problem.
>
> -Ted
>
> On 03/30/2017 11:30 AM, Adel Boutros wrote:
> > Hello Ted,
> >
> >
> > I thought the 0.8.0 release included the fixes to ignore IPv6 tests but it
> > doens't seem to be the case. Ganesh was working on fixing those.
> >
> > Do you confirm they are not included?
> > (http://qpid.2158936.n2.nabble.com/Fwd-GitHub-qpid-dispatch-pull-request-140-DISPATCH-216-Added-code-to-skip-system-te-td7658538.html#a7658571)
> >
> >
> > I launched the CI on the release candidate and got the same IPv6 failures
> > as before
> >
> >
> > The following tests FAILED with ipv6 errors:
> > 12 - router_policy_test (Failed)
> > 19 - system_tests_protocol_family (Failed)
> >
> >
> >
> > 12: Test command: /python278/bin/python
> > "/dispatch-workspace/build-dir/qpid-dispatch/tests/run.py" "-m" "unittest"
> > "-v" "router_policy_test"
> > 12: Test timeout computed to be: 1500
> > 12: Run python module 'unittest': PolicyError: u'Policy \'photoserver\' is
> > invalid: Policy vhost \'photoserver\' user group \'superuser\' option
> > \'remoteHosts\' connectionOption \'::1\' failed to translate:
> > \'\'HostStruct: \\\'::1\\\' failed to resolve: \\\'"HostStruct:
> > \\\'::1\\\' did not resolve to one of the supported address
> > family"\\\'\'\'.'
> >
> >
> > 19: error: [Errno 97] Address family not supported by protocol
> >
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Ted Ross <tr...@redhat.com>
> > Sent: Wednesday, March 29, 2017 1:32:42 PM
> > To: users@qpid.apache.org
> > Subject: Qpid Dispatch Router 0.8.0 Release Candidate 1
> >
> > The first release candidate for Qpid Dispatch Router 0.8.0 is ready for
> > evaluation.
> >
> > Build Artifacts:
> >
> >  https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.8.0-rc1/
> >
> > New Features:
> >
> >  DISPATCH-103 - Websocket Listeners
> >  DISPATCH-195 - Add support for transactional messages in t

Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

[Adel Boutros]

Thank you Alan,

As suggested, we will reconnect when we receive transport closed or connection 
forced exceptions.

Adel

Get Outlook for Android<https://aka.ms/ghei36>


From: Alan Conway
Sent: Thursday, March 30, 18:54
Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer
To: users@qpid.apache.org

On Thu, 2017-03-30 at 07:51 +, Adel Boutros wrote: > Thank you Rob, > > > I 
actually got this exception while a proton client was trying to > connect to a 
broker shutting down. > > > From your answer, I conclude that if the below 
error is thrown, the > retry connection mechanism should kick in. > > > Do you 
know if there are other possible exceptions I could get when > contacting a 
broker shutting down gracefully? > > > Regards, > > Adel > > 
 > From: Rob Godfrey > Sent: Wednesday, March 
29, 2017 11:18:58 PM > To: users@qpid.apache.org > Subject: Re: [Proton C++ 
0.16.0] Reconnect and reconnect timer > > Hi Adel, > > That error would be 
coming from the Java Broker... what this normally > means > is that the Virtual 
Host inside the broker is not currently active > ... this > may just be 
something like sending the message before the broker is > completely started... 
Because each virtual host has its own lifecycle > and > can be stopped and 
started independently of the port listener, the > fact > that the port is up 
doesn't actually mean the virtual host has > finished > started. > > -- Rob > 
On Wed, 29 Mar 2017 at 21:23, Adel Boutros > wrote: > > > Thank you Alan, > > > 
> > > As discussed with Andrew offline, we will develop our own reconnect > > 
strategy as we need it to handle all possible scenarios, examples: > > > > * 
Failure while establishing connection > > > > * Failure while sending a message 
> > > > * Failure while receiving a message > > > > and by failure we mean any 
failure regarding a lost connection. > > > > > > While testing our work, we 
noticed very rarely we were receiving > > the below > > exception. Do you know 
what it is about and how we should handle > > it? > > > > > > 
amqp:connection:forced:amqp:connection:forced: > > 
org.apache.qpid.server.virtualhost.VirtualHostUnavailableException: > > 
Virtualhost state UNAVAILABLE prevents the message from being sent > > > > > > 
Regards, > > > > Adel > > > >  > > From: Alan 
Conway > > Sent: Friday, March 24, 2017 2:47:56 PM > > To: 
users@qpid.apache.org > > Subject: Re: [Proton C++ 0.16.0] Reconnect and 
reconnect timer > > > > On Fri, 2017-03-17 at 17:21 +0100, Rabih M wrote: > > > 
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 behaves? > > > Does it try to 
reconnect only at connection start? and does it > > > try to > > > reconnect in 
the middle of an Amqp communication (after > > > sending/receiving > > > some 
messages)? > > > > > > On the other side, how to know that the max retries or 
dead line > > > timeout is > > > reached? > > > > > > > See 
include/proton/reconnect_timer.hpp for the things you can > > configure. This 
is still an "experimental" feature and could use > > some > > rounding out - 
your experience can be helpful with that. > > > > Currently this will reconnect 
on an unexpected disconnect - that is > > to > > say on_transport_closed() 
occurs before on_connection_closed() In short - transport closed and 
connection-forced are all you have to deal with, for now anyway. Long story: 
historically in C++ (and carried forward to proton) we only reconnect if the 
transport fails unexpectedly. The reasoning is, if you get a protocol error 
then you clearly haven't been disconnected, so no call for automatic 
re-connect. The AMQP spec does have a "connection-forced" error, and a 
reasonable interpretation of is "I'm disconnecting you on purpose but for 
reasons that might justify a reconnect attempt" Our C++ HA broker never used it 
because it is simpler and more robust to force a reconnect by just closing the 
socket rudely and letting nature take its course. However the Java broker does 
use it and it is standard AMQP, so proton will support it soon (and so should 
you...) It is also conceivable that the connection-forced error could carry 
additional information to be used in reconnecting, I'm not sure if it is in 
practice. - 
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional 
commands, e-mail: users-h...@qpid.apache.org

Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

[Adel Boutros]

I rechecked quickly and I have different behaviors on different OSes.


* Linux :

router_policy_test and system_tests_protocol_family failing as stated previously


*Solaris:

Only router_policy_test  is failing.

For system_tests_protocol_family, I have the message "Skipping test..IPV6 not 
enabled"


We have some other test failures on Solaris and Linux but we will need to debug 
them and we won't have time at the moment for them. I can send you a report 
with the failures if you wish.


Regards,

Adel


From: Ted Ross <tr...@redhat.com>
Sent: Thursday, March 30, 2017 2:48:10 PM
To: users@qpid.apache.org
Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

Adel,

The commits associated with that Jira and PR #140 are included in this
release candidate.  We'll need to investigate whether it regressed again
or if the commit didn't fix the problem.

-Ted

On 03/30/2017 11:30 AM, Adel Boutros wrote:
> Hello Ted,
>
>
> I thought the 0.8.0 release included the fixes to ignore IPv6 tests but it 
> doens't seem to be the case. Ganesh was working on fixing those.
>
> Do you confirm they are not included? 
> (http://qpid.2158936.n2.nabble.com/Fwd-GitHub-qpid-dispatch-pull-request-140-DISPATCH-216-Added-code-to-skip-system-te-td7658538.html#a7658571)
>
>
> I launched the CI on the release candidate and got the same IPv6 failures as 
> before
>
>
> The following tests FAILED with ipv6 errors:
> 12 - router_policy_test (Failed)
> 19 - system_tests_protocol_family (Failed)
>
>
>
> 12: Test command: /python278/bin/python 
> "/dispatch-workspace/build-dir/qpid-dispatch/tests/run.py" "-m" "unittest" 
> "-v" "router_policy_test"
> 12: Test timeout computed to be: 1500
> 12: Run python module 'unittest': PolicyError: u'Policy \'photoserver\' is 
> invalid: Policy vhost \'photoserver\' user group \'superuser\' option 
> \'remoteHosts\' connectionOption \'::1\' failed to translate: \'\'HostStruct: 
> \\\'::1\\\' failed to resolve: \\\'"HostStruct: \\\'::1\\\' did not resolve 
> to one of the supported address family"\\\'\'\'.'
>
>
> 19: error: [Errno 97] Address family not supported by protocol
>
>
> Regards,
>
> Adel
>
> 
> From: Ted Ross <tr...@redhat.com>
> Sent: Wednesday, March 29, 2017 1:32:42 PM
> To: users@qpid.apache.org
> Subject: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
> The first release candidate for Qpid Dispatch Router 0.8.0 is ready for
> evaluation.
>
> Build Artifacts:
>
>  https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.8.0-rc1/
>
> New Features:
>
>  DISPATCH-103 - Websocket Listeners
>  DISPATCH-195 - Add support for transactional messages in the Router
>  DISPATCH-441 - Support password environment variable in qdrouter config
>  DISPATCH-467 - Terminus renaming for autoLinks
>  DISPATCH-529 - Address annotation for Multi-Tenancy
>  DISPATCH-726 - Connection Property for Failover Servers
>
> Improvements:
>
>  DISPATCH-113 - expose NodeTracker::last_topology_change in management
>  DISPATCH-542 - Popup text for clients should indicate if the client
> is a sender or receiver
>  DISPATCH-543 - Initial load of topology page fetches too much
> information
>  DISPATCH-544 - Add ability to hide the info panel on the left of
> the topology page
>  DISPATCH-552 - Allow only one tree node to be expanded if there is
> a large number of routers
>  DISPATCH-553 - Add statistic counter to the "log" entity to count
> log events per severity
>  DISPATCH-559 - qdstat - Request only the columns that will be used
> in the display
>  DISPATCH-561 - Create python program that returns fake management data
>  DISPATCH-568 - Iterator module cleanup
>  DISPATCH-570 - Add some counts to qdstat -g
>  DISPATCH-572 - Adding log info with proton transport id and related
> remote IP/port
>  DISPATCH-576 - Use new log entity statistic counter in console
>  DISPATCH-578 - Dispatch trace logging forces all proton tracing on
>  DISPATCH-579 - Expose software version via management
>  DISPATCH-592 - Attempt to auto-login to the host:port that served
> the web page
>  DISPATCH-597 - Log enhancements
>  DISPATCH-600 - Support secure websockets
>  DISPATCH-602 - Add a favicon to the stand-alone router site
>  DISPATCH-606 - Default session window is too small, causing
> performance bottlenecks
>  DISPATCH-627 - BatchedSettlement test fails with timeout on slower
> systems
>  DISPATCH-629 - Add a protocol-version to the inter-router protocol
> to enable backward compatibi

Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

[Adel Boutros]

Hello Ted,


I thought the 0.8.0 release included the fixes to ignore IPv6 tests but it 
doens't seem to be the case. Ganesh was working on fixing those.

Do you confirm they are not included? 
(http://qpid.2158936.n2.nabble.com/Fwd-GitHub-qpid-dispatch-pull-request-140-DISPATCH-216-Added-code-to-skip-system-te-td7658538.html#a7658571)


I launched the CI on the release candidate and got the same IPv6 failures as 
before


The following tests FAILED with ipv6 errors:
12 - router_policy_test (Failed)
19 - system_tests_protocol_family (Failed)



12: Test command: /python278/bin/python 
"/dispatch-workspace/build-dir/qpid-dispatch/tests/run.py" "-m" "unittest" "-v" 
"router_policy_test"
12: Test timeout computed to be: 1500
12: Run python module 'unittest': PolicyError: u'Policy \'photoserver\' is 
invalid: Policy vhost \'photoserver\' user group \'superuser\' option 
\'remoteHosts\' connectionOption \'::1\' failed to translate: \'\'HostStruct: 
\\\'::1\\\' failed to resolve: \\\'"HostStruct: \\\'::1\\\' did not resolve to 
one of the supported address family"\\\'\'\'.'


19: error: [Errno 97] Address family not supported by protocol


Regards,

Adel


From: Ted Ross 
Sent: Wednesday, March 29, 2017 1:32:42 PM
To: users@qpid.apache.org
Subject: Qpid Dispatch Router 0.8.0 Release Candidate 1

The first release candidate for Qpid Dispatch Router 0.8.0 is ready for
evaluation.

Build Artifacts:

 https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.8.0-rc1/

New Features:

 DISPATCH-103 - Websocket Listeners
 DISPATCH-195 - Add support for transactional messages in the Router
 DISPATCH-441 - Support password environment variable in qdrouter config
 DISPATCH-467 - Terminus renaming for autoLinks
 DISPATCH-529 - Address annotation for Multi-Tenancy
 DISPATCH-726 - Connection Property for Failover Servers

Improvements:

 DISPATCH-113 - expose NodeTracker::last_topology_change in management
 DISPATCH-542 - Popup text for clients should indicate if the client
is a sender or receiver
 DISPATCH-543 - Initial load of topology page fetches too much
information
 DISPATCH-544 - Add ability to hide the info panel on the left of
the topology page
 DISPATCH-552 - Allow only one tree node to be expanded if there is
a large number of routers
 DISPATCH-553 - Add statistic counter to the "log" entity to count
log events per severity
 DISPATCH-559 - qdstat - Request only the columns that will be used
in the display
 DISPATCH-561 - Create python program that returns fake management data
 DISPATCH-568 - Iterator module cleanup
 DISPATCH-570 - Add some counts to qdstat -g
 DISPATCH-572 - Adding log info with proton transport id and related
remote IP/port
 DISPATCH-576 - Use new log entity statistic counter in console
 DISPATCH-578 - Dispatch trace logging forces all proton tracing on
 DISPATCH-579 - Expose software version via management
 DISPATCH-592 - Attempt to auto-login to the host:port that served
the web page
 DISPATCH-597 - Log enhancements
 DISPATCH-600 - Support secure websockets
 DISPATCH-602 - Add a favicon to the stand-alone router site
 DISPATCH-606 - Default session window is too small, causing
performance bottlenecks
 DISPATCH-627 - BatchedSettlement test fails with timeout on slower
systems
 DISPATCH-629 - Add a protocol-version to the inter-router protocol
to enable backward compatibility
 DISPATCH-641 - Make containerId attribute work with clients

Bugs Fixed:

 DISPATCH-55 - Qdrouterd does not exit when service port is unavailable
 DISPATCH-216 - system_tests_protocol_family fails on systems with
no IPv6
 DISPATCH-296 - segfault on router startup
 DISPATCH-301 - Some unit tests fail with workerThreads are set to 4
 DISPATCH-314 - If a router has a normal listener, show it in a
different color on the topology page
 DISPATCH-324 - Improve initial layout of topology node
 DISPATCH-344 - memory growth after repeated calls from qdstat -m
 DISPATCH-352 - Crash with empty configuration file
 DISPATCH-355 - query fails with what seems to be the error of a
previous command
 DISPATCH-357 - Address field is empty for link routed links in the
qdstat "links" output
 DISPATCH-433 - Navigating to console from bookmark displays empty
page with just toolbars
 DISPATCH-451 - [AMQP] Hard coded session capacity should be
configurable
 DISPATCH-503 - [display_name] successful test runs  have non-ascii
characters in router log
 DISPATCH-504 - [display_name] successful test runs have invalid
message errors  in router log
 DISPATCH-506 - Detach with no "error" sent by router on client TCP
connection dropped
 DISPATCH-516 - Core dump when displayname IO adapter receives
message with no reply-to
 DISPATCH-526 - Coverity scan reported memory leaks in Qpid Dispatch
0.7.0
 DISPATCH-527 - The $displayname 

Re: [Java Broker - 6.0.4] Dojo toolkit dependency

[Adel Boutros]

Thank you Keith for the valuable information.


Indeed, we have developed a Java API to manage the Broker via REST (Using 
Sprint Rest Template). However for now, we have been using unsecured channels 
for it.


Regards,

Adel


From: Keith W <keith.w...@gmail.com>
Sent: Thursday, March 30, 2017 10:22:28 AM
To: users@qpid.apache.org
Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency

On 30 March 2017 at 08:49, Adel Boutros <adelbout...@live.com> wrote:
> Thank you Rob,
>
>
> Actually, we were wondering about the "dojo-1.10.3-distribution.zip" 
> available under the lib directory of the downloaded broker zip. So from your 
> answers, you only use it in the web console.
>
>

Yes - this is correct.  It is used only by the web management console.

> One last question, what happens if we delete this dependency? Could we still 
> contact the broker via REST using SSL/SASL to manage queues, exchanges, etc?

You'll see 404 errors if you attempt to use the Web Management Console
but no harm is caused.

The REST API, the Broker's ability to offer TLS (aka. SSL) and to
offer SASL based authentication are all unaffected.

Incidentally, if you are making programmatic use of the REST API, we
recommend that you make use of preemptive authentication over a secure
channel (that is. present an Authorization: header on your programatic
HTTP request).   The will give you a simpler application which makes
fewer network interactions.  You can do this from the command line
using cURL (https://curl.haxx.se/docs/manpage.html#-u)



>
>
> Regards,
>
> Adel
>
> 
> From: Rob Godfrey <rob.j.godf...@gmail.com>
> Sent: Wednesday, March 29, 2017 11:38:30 PM
> To: users@qpid.apache.org
> Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency
>
> Are you talking dojo itself, or the fact that the http-management plugin
> also notes that it "This bundles portions of crypto-js, which is under the
> MIT licence".
>
> The only "cryptographic functions" used within the web console are those
> necessary to implement the necessary SASL authentication mechanisms.  In
> particular SHA-1, SHA-256 (and for historical reasons MD5) hashing.  There
> is no encryption used within the console (other than TLS through the
> standard browser mechanism).  The use of crypto-js code was because dojo
> didn't have an implementation of the necessary HMAC mechanisms for SHA-1 /
> SHA-256 if I remember correctly.  (See https://tools.ietf.org/html/rfc5802
> and https://tools.ietf.org/html/rfc7677 for details of the SCRAM-SHA* SASL
> mechanisms).
>
> Hope this helps,
> Rob
>
>
>
> On 29 March 2017 at 21:17, Adel Boutros <adelbout...@live.com> wrote:
>
>> Hello,
>>
>>
>> While our legal team was reviewing the Broker's packaged dependencies and
>> their licenses, they had some questions regarding Dojo toolkit materials
>> which I hope you can help me with:
>>
>>
>> * Could you please list all cryptographic means contained in the dojo
>> materials used?
>>
>>
>> * Could you please describe:
>>
>> 1) the purpose(s) for which the dojo materials use these cryptographic
>> means
>>
>> 2) whether these means will be accessible to end users
>>
>>
>> * Why is this dependency needed and could we omit it from distribution?
>>
>>
>> Regards,
>>
>> Adel
>>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

[Adel Boutros]

Thank you Rob,


I actually got this exception while a proton client was trying to connect to a 
broker shutting down.


>From your answer, I conclude that if the below error is thrown, the retry 
>connection mechanism should kick in.


Do you know if there are other possible exceptions I could get when contacting 
a broker shutting down gracefully?


Regards,

Adel


From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Wednesday, March 29, 2017 11:18:58 PM
To: users@qpid.apache.org
Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

Hi Adel,

That error would be coming from the Java Broker... what this normally means
is that the Virtual Host inside the broker is not currently active ... this
may just be something like sending the message before the broker is
completely started... Because each virtual host has its own lifecycle and
can be stopped and started independently of the port listener, the fact
that the port is up doesn't actually mean the virtual host has finished
started.

-- Rob
On Wed, 29 Mar 2017 at 21:23, Adel Boutros <adelbout...@live.com> wrote:

> Thank you Alan,
>
>
> As discussed with Andrew offline, we will develop our own reconnect
> strategy as we need it to handle all possible scenarios, examples:
>
> * Failure while establishing connection
>
> * Failure while sending a message
>
> * Failure while receiving a message
>
> and by failure we mean any failure regarding a lost connection.
>
>
> While testing our work, we noticed very rarely we were receiving the below
> exception. Do you know what it is about and how we should handle it?
>
>
> amqp:connection:forced:amqp:connection:forced:
> org.apache.qpid.server.virtualhost.VirtualHostUnavailableException:
> Virtualhost state UNAVAILABLE prevents the message from being sent
>
>
> Regards,
>
> Adel
>
> 
> From: Alan Conway <acon...@redhat.com>
> Sent: Friday, March 24, 2017 2:47:56 PM
> To: users@qpid.apache.org
> Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer
>
> On Fri, 2017-03-17 at 17:21 +0100, Rabih M wrote:
> > 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 behaves?
> > Does it try to reconnect only at connection start? and does it try to
> > reconnect in the middle of an Amqp communication (after
> > sending/receiving
> > some messages)?
> >
> > On the other side, how to know that the max retries or dead line
> > timeout is
> > reached?
> >
>
> See include/proton/reconnect_timer.hpp for the things you can
> configure. This is still an "experimental" feature and could use some
> rounding out - your experience can be helpful with that.
>
> Currently this will reconnect on an unexpected disconnect - that is to
> say on_transport_closed() occurs before on_connection_closed()
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Java Broker - 6.0.4] Dojo toolkit dependency

[Adel Boutros]

Thank you Rob,


Actually, we were wondering about the "dojo-1.10.3-distribution.zip" available 
under the lib directory of the downloaded broker zip. So from your answers, you 
only use it in the web console.


One last question, what happens if we delete this dependency? Could we still 
contact the broker via REST using SSL/SASL to manage queues, exchanges, etc?


Regards,

Adel


From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Wednesday, March 29, 2017 11:38:30 PM
To: users@qpid.apache.org
Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency

Are you talking dojo itself, or the fact that the http-management plugin
also notes that it "This bundles portions of crypto-js, which is under the
MIT licence".

The only "cryptographic functions" used within the web console are those
necessary to implement the necessary SASL authentication mechanisms.  In
particular SHA-1, SHA-256 (and for historical reasons MD5) hashing.  There
is no encryption used within the console (other than TLS through the
standard browser mechanism).  The use of crypto-js code was because dojo
didn't have an implementation of the necessary HMAC mechanisms for SHA-1 /
SHA-256 if I remember correctly.  (See https://tools.ietf.org/html/rfc5802
and https://tools.ietf.org/html/rfc7677 for details of the SCRAM-SHA* SASL
mechanisms).

Hope this helps,
Rob



On 29 March 2017 at 21:17, Adel Boutros <adelbout...@live.com> wrote:

> Hello,
>
>
> While our legal team was reviewing the Broker's packaged dependencies and
> their licenses, they had some questions regarding Dojo toolkit materials
> which I hope you can help me with:
>
>
> * Could you please list all cryptographic means contained in the dojo
> materials used?
>
>
> * Could you please describe:
>
> 1) the purpose(s) for which the dojo materials use these cryptographic
> means
>
> 2) whether these means will be accessible to end users
>
>
> * Why is this dependency needed and could we omit it from distribution?
>
>
> Regards,
>
> Adel
>

Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

[Adel Boutros]

Thank you Alan,


As discussed with Andrew offline, we will develop our own reconnect strategy as 
we need it to handle all possible scenarios, examples:

* Failure while establishing connection

* Failure while sending a message

* Failure while receiving a message

and by failure we mean any failure regarding a lost connection.


While testing our work, we noticed very rarely we were receiving the below 
exception. Do you know what it is about and how we should handle it?


amqp:connection:forced:amqp:connection:forced: 
org.apache.qpid.server.virtualhost.VirtualHostUnavailableException: Virtualhost 
state UNAVAILABLE prevents the message from being sent


Regards,

Adel


From: Alan Conway 
Sent: Friday, March 24, 2017 2:47:56 PM
To: users@qpid.apache.org
Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

On Fri, 2017-03-17 at 17:21 +0100, Rabih M wrote:
> 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 behaves?
> Does it try to reconnect only at connection start? and does it try to
> reconnect in the middle of an Amqp communication (after
> sending/receiving
> some messages)?
>
> On the other side, how to know that the max retries or dead line
> timeout is
> reached?
>

See include/proton/reconnect_timer.hpp for the things you can
configure. This is still an "experimental" feature and could use some
rounding out - your experience can be helpful with that.

Currently this will reconnect on an unexpected disconnect - that is to
say on_transport_closed() occurs before on_connection_closed()



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

[Java Broker - 6.0.4] Dojo toolkit dependency

[Adel Boutros]

Hello,


While our legal team was reviewing the Broker's packaged dependencies and their 
licenses, they had some questions regarding Dojo toolkit materials which I hope 
you can help me with:


* Could you please list all cryptographic means contained in the dojo materials 
used?


* Could you please describe:

1) the purpose(s) for which the dojo materials use these cryptographic means

2) whether these means will be accessible to end users


* Why is this dependency needed and could we omit it from distribution?


Regards,

Adel

Re: Qpid Dispatch Release Plans

[Adel Boutros]

Hello Ted,

What about:
* DISPATCH-627
* DISPATCH-624

+1 for release model.

Regards,
Adel


From: Ted Ross 
Sent: Wednesday, March 22, 2017 2:43:42 PM
To: users@qpid.apache.org
Subject: Qpid Dispatch Release Plans

A couple of topics for discussion:

Qpid Dispatch Router 0.8.0 release
==

As of now, there are 116 resolved issues queued up for 0.8.0.  I'd like
to wrap up this release in the next week.  I plan to defer all of the
pending features to the next release.

If anyone has any bug fixes they would like to see included in this
release that are not already set to "Fix Version: 0.8.0", please put
them on the list.


Release Numbering
=

I'd like to propose that the next release (after 0.8.0) be called 1.0.0.

The x.y.z release numbering would follow the normal expectations:

  - All releases with the same 'x' shall be interoprable and we commit
to not breaking anyone's configurations as the project evolves
through a single major (x) version.
  - Minor (y) releases shall be on a semi-regular cadence and shall
contain feature additions as well as rolled-up bug fixes.
  - z releases shall be for bug fixes only and will be used as-needed.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Corrupt artifacts on Qpid release web page

[Adel Boutros]

Could the issue be I am behind a proxy?


However, I will not be able to test otherwise before tonight.


Just to summarize with my Chrome or Firexfox:

* corrupt: 
http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/qpid-java-6.1.1.tar.gz

* works: 
http://www.apache.org/dyn/closer.cgi?filename=qpid/java/6.1.1/qpid-java-6.1.1.tar.gz=download


I asked other colleagues and they have the same issue.


Regards,

Adel


From: Justin Ross <justin.r...@gmail.com>
Sent: Monday, March 20, 2017 2:47:55 PM
To: users@qpid.apache.org
Subject: Re: Corrupt artifacts on Qpid release web page

On Mon, Mar 20, 2017 at 6:26 AM, Rob Godfrey <rob.j.godf...@gmail.com>
wrote:

> On 20 March 2017 at 14:23, Adel Boutros <adelbout...@live.com> wrote:
>
> > Hello Rob,
> >
> >
> > I just saw your mail and I confirm what you propose works correctly. I
> > opened your link via chrome and it downloaded the correct package this
> time.
> >
> >
> > Please note this is the case for all the artifacts proposed on the
> website.
> >
> >
> > So are you going to fix them all?
> >
>
> I'm not sure what the intent of the page is, whether the idea is to allow
> people the (interactive) choice to download from one of several alternative
> mirrors, or whether it should give the impression of just directly
> downloading from the mirror that Apache deems the most appropriate.
>
> Anyone with more involvement in the website want to comment here?
>

I don't have a strong preference.  I think the behavior we have is the one
Qpid started out with way back.  For some, it may be attractive to select a
mirror.  For me, I'd let the CGI script do it.

Data points: httpd gives you a mirrored download directly, but it's using
its own CGI script.  Lucene goes to the mirror list.  ActiveMQ gives you
the download directly.

I still don't understand what combination of OS and browser versions is
giving Adel the wrong content type for the mirror list page.  It doesn't
reproduce for me.

Re: Corrupt artifacts on Qpid release web page

[Adel Boutros]

It seems mails have a maximum length for a line after which the line is split 
in two. You were able to see a download page, because you opened a part of the 
URL I sent due to that.


You went to "http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/;

instead of 
"http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/qpid-java-6.1.1.tar.gz;


As I can see how my email appeared to you.


Regards,

Adel




From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Monday, March 20, 2017 2:26:36 PM
To: users@qpid.apache.org
Subject: Re: Corrupt artifacts on Qpid release web page

On 20 March 2017 at 14:23, Adel Boutros <adelbout...@live.com> wrote:

> Hello Rob,
>
>
> I just saw your mail and I confirm what you propose works correctly. I
> opened your link via chrome and it downloaded the correct package this time.
>
>
> Please note this is the case for all the artifacts proposed on the website.
>
>
> So are you going to fix them all?
>

I'm not sure what the intent of the page is, whether the idea is to allow
people the (interactive) choice to download from one of several alternative
mirrors, or whether it should give the impression of just directly
downloading from the mirror that Apache deems the most appropriate.

Anyone with more involvement in the website want to comment here?

-- Rob


>
>
> Regards,
>
> Adel
>
> 
> From: Rob Godfrey <rob.j.godf...@gmail.com>
> Sent: Monday, March 20, 2017 2:13:07 PM
> To: users@qpid.apache.org
> Subject: Re: Corrupt artifacts on Qpid release web page
>
> So, after little bit of digging around [1], a URL of the form
> http://www.apache.org/dyn/closer.cgi?filename==download
> will automatically download from the suggested mirror, so in Adel's example
> above:
>
> curl -O '
> http://www.apache.org/dyn/closer.cgi?filename=qpid/java/
> 6.1.1/qpid-java-6.1.1.tar.gz=download
> '
>
> should get the archive file correctly
>
> -- Rob
>
>
> [1] http://apache.org/dev/release-download-pages.html#closer
>
> On 20 March 2017 at 13:43, Lorenz Quack <quack.lor...@gmail.com> wrote:
>
> > Hello Adel,
> >
> > I have problems reproducing. On both windows (IE & Chrome) and
> > Linux (Firefox) the download does not start automatically.
> >
> > In any case, did you check the content of the thing you downloaded
> > to see whether it is a html page or a binary (probably gz)?
> > For example opening it in a text editor.
> >
> > In case it is as I suspect the html page you could try using
> > cURL's -L switch to make it follow redirects.
> >
> > Kind regards,
> > Lorenz
> >
> >
> >
> > On 20/03/17 10:24, Adel Boutros wrote:
> >
> >> Hello Rob, Lorenz,
> >>
> >>
> >> When you hover on any of the links under "download" section on
> >> https://qpid.apache.org/releases/qpid-java-6.1.1/index.html, you got
> the
> >> below link which I am trying to download.
> >>
> >> On windows, I click on the link and it is automatically downloaded. So I
> >> am not explicitly downloading an html page.
> >>
> >>
> >> So it seems the web page has an invalid link.
> >>
> >> This is what I am experiencing with all artifacts listed.
> >>
> >>
> >> Regards,
> >>
> >> Adel
> >>
> >> 
> >> From: Lorenz Quack <quack.lor...@gmail.com>
> >> Sent: Monday, March 20, 2017 11:08:44 AM
> >> To: users@qpid.apache.org
> >> Subject: Re: Corrupt artifacts on Qpid release web page
> >>
> >> Hello Adel,
> >>
> >> That is not the link to the actual file. There is one more level of
> >> indirection.
> >> You are downloading a html page.
> >>
> >> Kind regards,
> >> Lorenz
> >>
> >>
> >> On 20/03/17 09:37, Adel Boutros wrote:
> >>
> >>> Hello Lorenz,
> >>>
> >>>
> >>> I tried on Windows and Linux<http://www.apache.org/dy
> >>> n/closer.lua/qpid/java/6.1.1/binaries/qpid-broker-6.1.1-bin.tar.gz>
> >>>
> >>>
> >>> Linux:
> >>>
> >>> curl -O http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/qpid-
> >>> java-6.1.1.tar.gz
> >>>
> >>> tar xfz qpid-java-6.1.1.tar.gz
> >>>
> >>>
> >>> gzip: stdin: not in gzip format
> >>> tar: Child returned status 1
> >>> tar: Error is not recoverable: exiting now
>

Re: Corrupt artifacts on Qpid release web page

[Adel Boutros]

Hello Rob,


I just saw your mail and I confirm what you propose works correctly. I opened 
your link via chrome and it downloaded the correct package this time.


Please note this is the case for all the artifacts proposed on the website.


So are you going to fix them all?


Regards,

Adel


From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Monday, March 20, 2017 2:13:07 PM
To: users@qpid.apache.org
Subject: Re: Corrupt artifacts on Qpid release web page

So, after little bit of digging around [1], a URL of the form
http://www.apache.org/dyn/closer.cgi?filename==download
will automatically download from the suggested mirror, so in Adel's example
above:

curl -O '
http://www.apache.org/dyn/closer.cgi?filename=qpid/java/6.1.1/qpid-java-6.1.1.tar.gz=download
'

should get the archive file correctly

-- Rob


[1] http://apache.org/dev/release-download-pages.html#closer

On 20 March 2017 at 13:43, Lorenz Quack <quack.lor...@gmail.com> wrote:

> Hello Adel,
>
> I have problems reproducing. On both windows (IE & Chrome) and
> Linux (Firefox) the download does not start automatically.
>
> In any case, did you check the content of the thing you downloaded
> to see whether it is a html page or a binary (probably gz)?
> For example opening it in a text editor.
>
> In case it is as I suspect the html page you could try using
> cURL's -L switch to make it follow redirects.
>
> Kind regards,
> Lorenz
>
>
>
> On 20/03/17 10:24, Adel Boutros wrote:
>
>> Hello Rob, Lorenz,
>>
>>
>> When you hover on any of the links under "download" section on
>> https://qpid.apache.org/releases/qpid-java-6.1.1/index.html, you got the
>> below link which I am trying to download.
>>
>> On windows, I click on the link and it is automatically downloaded. So I
>> am not explicitly downloading an html page.
>>
>>
>> So it seems the web page has an invalid link.
>>
>> This is what I am experiencing with all artifacts listed.
>>
>>
>> Regards,
>>
>> Adel
>>
>> 
>> From: Lorenz Quack <quack.lor...@gmail.com>
>> Sent: Monday, March 20, 2017 11:08:44 AM
>> To: users@qpid.apache.org
>> Subject: Re: Corrupt artifacts on Qpid release web page
>>
>> Hello Adel,
>>
>> That is not the link to the actual file. There is one more level of
>> indirection.
>> You are downloading a html page.
>>
>> Kind regards,
>> Lorenz
>>
>>
>> On 20/03/17 09:37, Adel Boutros wrote:
>>
>>> Hello Lorenz,
>>>
>>>
>>> I tried on Windows and Linux<http://www.apache.org/dy
>>> n/closer.lua/qpid/java/6.1.1/binaries/qpid-broker-6.1.1-bin.tar.gz>
>>>
>>>
>>> Linux:
>>>
>>> curl -O http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/qpid-
>>> java-6.1.1.tar.gz
>>>
>>> tar xfz qpid-java-6.1.1.tar.gz
>>>
>>>
>>> gzip: stdin: not in gzip format
>>> tar: Child returned status 1
>>> tar: Error is not recoverable: exiting now
>>>
>>>
>>>
>>> Windows (Using B1 archiver):
>>>
>>> I can extract qpid-java-6.1.1.tar.gz to qpid-java-6.1.1.tar
>>> I cannot extract qpid-java-6.1.1.tar (Archive is broker or damaged)
>>>
>>>
>>>
>>> Regards,
>>>
>>> Adel
>>>
>>> ________
>>> From: Lorenz Quack <quack.lor...@gmail.com>
>>> Sent: Monday, March 20, 2017 10:13:59 AM
>>> To: users@qpid.apache.org
>>> Subject: Re: Corrupt artifacts on Qpid release web page
>>>
>>> Hi,
>>>
>>> I just tried the source bundle of the "Qpid for Java 6.1.1," release
>>> without issues.
>>> I used the command
>>> $ tar xfz qpid-java-6.1.1.tar.gz
>>> to unpack the source bundle.
>>>
>>> With which artefacts do you experience problems specifically?
>>> What tools are you using to extract the files?
>>> Windows, Linux?
>>>
>>> Kind regards,
>>> Lorenz
>>>
>>>
>>> On 20/03/17 09:05, Adel Boutros wrote:
>>>
>>>> Hello,
>>>>
>>>>
>>>> It seems all ".tar" artifacts are corrupt when accessed from
>>>> https://qpid.apache.org/releases.
>>>>
>>>>
>>>> I can download all ".tar.gz" and unzip them. However, I cannot extract
>>>> the ".tar".
>>>>
>>>>
>>>> Are you aware of such issue?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Adel
>>>>
>>>>
>>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>
>>>
>>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Corrupt artifacts on Qpid release web page

[Adel Boutros]

Ok, so here is what I found:


The ".tar.gz" seems to be correct when downloaded by direct click on the web 
page. However, when I extract it using B1 archiver, the ".tar" is indeed a web 
page html.


".tar.gz" (opened in notepad++)


‹  Í\{sÛ8’ÿÛúX¥Òo'Ž­)ÇÎõÇy67uu5‘ …„$ Ôc¯æ»_7 
R¤,Ù’í©»­‰‚À�F£ÑÝhîÉ?.>ŸßüqýŽ 
u–ö:'øCRš'§]–w±‚Ѩ×!ä$cš’pH¥bú´[êØ{Õ�½j]xìGÉG§Ýÿô~?óÎEVPÍ)ë’PäšåÐëòÝ)‹Öè—ÓŒ�vGœ�
 !u£é˜Gzx±™g¶Ϲæ4õTHSvºs *”¼Ð\ä
¤�"c¤ #"&7CFÎ


".tar" (Opened in notepad++ after extraction via B1 archiver)





  
  
  
  
  https://www.apache.org/dyn/closer.cgi; />


Direct link (If put in chrome and click enter, It will open a save window to 
download it):

http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/qpid-java-6.1.1.tar.gz


Regards,

Adel




From: Lorenz Quack <quack.lor...@gmail.com>
Sent: Monday, March 20, 2017 1:43:21 PM
To: users@qpid.apache.org
Subject: Re: Corrupt artifacts on Qpid release web page

Hello Adel,

I have problems reproducing. On both windows (IE & Chrome) and
Linux (Firefox) the download does not start automatically.

In any case, did you check the content of the thing you downloaded
to see whether it is a html page or a binary (probably gz)?
For example opening it in a text editor.

In case it is as I suspect the html page you could try using
cURL's -L switch to make it follow redirects.

Kind regards,
Lorenz


On 20/03/17 10:24, Adel Boutros wrote:
> Hello Rob, Lorenz,
>
>
> When you hover on any of the links under "download" section on 
> https://qpid.apache.org/releases/qpid-java-6.1.1/index.html, you got the 
> below link which I am trying to download.
>
> On windows, I click on the link and it is automatically downloaded. So I am 
> not explicitly downloading an html page.
>
>
> So it seems the web page has an invalid link.
>
> This is what I am experiencing with all artifacts listed.
>
>
> Regards,
>
> Adel
>
> 
> From: Lorenz Quack <quack.lor...@gmail.com>
> Sent: Monday, March 20, 2017 11:08:44 AM
> To: users@qpid.apache.org
> Subject: Re: Corrupt artifacts on Qpid release web page
>
> Hello Adel,
>
> That is not the link to the actual file. There is one more level of
> indirection.
> You are downloading a html page.
>
> Kind regards,
> Lorenz
>
>
> On 20/03/17 09:37, Adel Boutros wrote:
>> Hello Lorenz,
>>
>>
>> I tried on Windows and 
>> Linux<http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/binaries/qpid-broker-6.1.1-bin.tar.gz>
>>
>>
>> Linux:
>>
>> curl -O 
>> http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/qpid-java-6.1.1.tar.gz
>>
>> tar xfz qpid-java-6.1.1.tar.gz
>>
>>
>> gzip: stdin: not in gzip format
>> tar: Child returned status 1
>> tar: Error is not recoverable: exiting now
>>
>>
>>
>> Windows (Using B1 archiver):
>>
>> I can extract qpid-java-6.1.1.tar.gz to qpid-java-6.1.1.tar
>> I cannot extract qpid-java-6.1.1.tar (Archive is broker or damaged)
>>
>>
>>
>> Regards,
>>
>> Adel
>>
>> 
>> From: Lorenz Quack <quack.lor...@gmail.com>
>> Sent: Monday, March 20, 2017 10:13:59 AM
>> To: users@qpid.apache.org
>> Subject: Re: Corrupt artifacts on Qpid release web page
>>
>> Hi,
>>
>> I just tried the source bundle of the "Qpid for Java 6.1.1," release
>> without issues.
>> I used the command
>> $ tar xfz qpid-java-6.1.1.tar.gz
>> to unpack the source bundle.
>>
>> With which artefacts do you experience problems specifically?
>> What tools are you using to extract the files?
>> Windows, Linux?
>>
>> Kind regards,
>> Lorenz
>>
>>
>> On 20/03/17 09:05, Adel Boutros wrote:
>>> Hello,
>>>
>>>
>>> It seems all ".tar" artifacts are corrupt when accessed from 
>>> https://qpid.apache.org/releases.
>>>
>>>
>>> I can download all ".tar.gz" and unzip them. However, I cannot extract the 
>>> ".tar".
>>>
>>>
>>> Are you aware of such issue?
>>>
>>>
>>> Regards,
>>>
>>> Adel
>>>
>>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Corrupt artifacts on Qpid release web page

[Adel Boutros]

Hello Rob, Lorenz,


When you hover on any of the links under "download" section on 
https://qpid.apache.org/releases/qpid-java-6.1.1/index.html, you got the below 
link which I am trying to download.

On windows, I click on the link and it is automatically downloaded. So I am not 
explicitly downloading an html page.


So it seems the web page has an invalid link.

This is what I am experiencing with all artifacts listed.


Regards,

Adel


From: Lorenz Quack <quack.lor...@gmail.com>
Sent: Monday, March 20, 2017 11:08:44 AM
To: users@qpid.apache.org
Subject: Re: Corrupt artifacts on Qpid release web page

Hello Adel,

That is not the link to the actual file. There is one more level of
indirection.
You are downloading a html page.

Kind regards,
Lorenz


On 20/03/17 09:37, Adel Boutros wrote:
> Hello Lorenz,
>
>
> I tried on Windows and 
> Linux<http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/binaries/qpid-broker-6.1.1-bin.tar.gz>
>
>
> Linux:
>
> curl -O 
> http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/qpid-java-6.1.1.tar.gz
>
> tar xfz qpid-java-6.1.1.tar.gz
>
>
> gzip: stdin: not in gzip format
> tar: Child returned status 1
> tar: Error is not recoverable: exiting now
>
>
>
> Windows (Using B1 archiver):
>
> I can extract qpid-java-6.1.1.tar.gz to qpid-java-6.1.1.tar
> I cannot extract qpid-java-6.1.1.tar (Archive is broker or damaged)
>
>
>
> Regards,
>
> Adel
>
> 
> From: Lorenz Quack <quack.lor...@gmail.com>
> Sent: Monday, March 20, 2017 10:13:59 AM
> To: users@qpid.apache.org
> Subject: Re: Corrupt artifacts on Qpid release web page
>
> Hi,
>
> I just tried the source bundle of the "Qpid for Java 6.1.1," release
> without issues.
> I used the command
> $ tar xfz qpid-java-6.1.1.tar.gz
> to unpack the source bundle.
>
> With which artefacts do you experience problems specifically?
> What tools are you using to extract the files?
> Windows, Linux?
>
> Kind regards,
> Lorenz
>
>
> On 20/03/17 09:05, Adel Boutros wrote:
>> Hello,
>>
>>
>> It seems all ".tar" artifacts are corrupt when accessed from 
>> https://qpid.apache.org/releases.
>>
>>
>> I can download all ".tar.gz" and unzip them. However, I cannot extract the 
>> ".tar".
>>
>>
>> Are you aware of such issue?
>>
>>
>> Regards,
>>
>> Adel
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Corrupt artifacts on Qpid release web page

[Adel Boutros]

Hello Rob, Lorenz,

When you hover on any of the links under "download" section on
https://qpid.apache.org/releases/qpid-java-6.1.1/index.html, you got the
below link which I am trying to download.
On windows, I click on the link and it is automatically downloaded. So I am
not explicitly downloading an html page.

So it seems the web page has an invalid link. 
This is what I am experiencing with all artifacts listed.

Regards,
Adel



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Corrupt-artifacts-on-Qpid-release-web-page-tp7661130p7661140.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Qpid Broker - 6.0.4] Junit testable?

[Adel Boutros]

Hello Rob,


We have many types of testing. Some of them do not require testing 
administration. So queues could be static at the start of the tests.

In that case, loading JSON from memory would solve the issue for these tests.

However, we would need to wrap this in Java to allow the users writing tests to 
configure the queues without really knowing the content of the JSON. We assume 
our users will only configure the brokers via Java or REST so they shouldn't 
know how the broker actually configures the queues behind the scene.


We have also another alternative as we have developed internally a Java API to 
contact the REST management of the broker, all we actually need now is a proper 
way to get the dynamic ports.


Regards,

Adel


From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Monday, March 20, 2017 11:10:11 AM
To: keith.w...@gmail.com; users@qpid.apache.org
Subject: Re: [Qpid Broker - 6.0.4] Junit testable?

On Fri, 17 Mar 2017 at 16:10, Adel Boutros <adelbout...@live.com> wrote:

> Indeed, most users will most probably inject a JMS connection using Spring
> annotations. So testing it against an easy to embedd broker would be highly
> appreciated because Spring already provides a lot of helpers in testing.
>
>
> The problem is that each broker respects the specifications the way it say
> it fit. We had issues with ActiveMQ when configuring topic linked to queues
> with advanced filtering. This is why embeddable broker should be as close
> as possible to the production broker to avoid skipping some bugs or
> unsupported cases.
>
>
> @Keith,
>
> Indeed we could configure queues using REST but then again we need 2
> things:
>
> * Know the port
>
> * Develop a Java like API for rest operations (Not all users knows the
> REST calls of the broker
>
>
> This is why I was saying the Qpid Broker is not very friendly to use with
> JMS.
>
>
> I will give a look at the classes you mentioned.



Hi Adel... do you really need a way to dynamically configure the embedded
broker after it has started, or do you just need a way to inject
configuration into the embedded broker before it starts (and without
requiring a config file to do so)?  I have some code sitting on my laptop
which allows for a broker to be started with in memory configuration
provided in the form of a JSON String... would that sort of solution work
for you?

-- Rob

>
>
>
> Regards,
>
> Adel
>
> 
> From: Dan Langford <danlangf...@gmail.com>
> Sent: Friday, March 17, 2017 3:46:46 PM
> To: keith.w...@gmail.com; users@qpid.apache.org
> Subject: Re: [Qpid Broker - 6.0.4] Junit testable?
>
> You already mentioned HornetQ I would also toss out there ActiveMQ as one
> that is fantastic at embedding. In my Java projects I code to JMS and in
> Unit tests I mock out JMS apis because I am just testing MY code. Sometimes
> it's just easier or a more thorough test to include a broker especially
> since so much config is moving into Java code these days (spring JMS
> annotations) and for those I use ActiveMQ embedded. Once I get up to
> integration type tests we have all of our code tests against a few non-prod
> Qpid servers we have. We actually have Dev, Test, Stage, Load lanes before
> getting up into prod. That's probably more lanes than most people need but
> we have 80-100 little tiny applications that we are regularly working on so
> those lanes help us manage their progression towards prod.
>
> Maybe if you mocked JMS, used an embedded broker that implements AMQP, and
> then set up a Staging Qpid server that would give you the confidence you
> need to advance to Production
>
>
> On Fri, Mar 17, 2017 at 8:27 AM Keith W <keith.w...@gmail.com> wrote:
>
> > Hi Adel
> >
> > There is a recognition that the embed-ability of the Qpid Broker for
> > Java is not what it should be.   We have been making incremental
> > improvements with each major release but things still aren't ideal
> > state.
> >
> > For the dynamically bound port number, QPID-7597 changes the Broker so
> > that it is available from the model:  Port#getBoundPort().  This will
> > be part of the next major release.  As things stand in 6.0,
> > unfortunately, there is no clean way to discover the actual bound
> > port.  The best you could do it scrape the log, or intercept the event
> > logging so pull out the bound port number for AMQP and HTTP, neither
> > of which are clean I know.  The classes to look at are:
> > org.apache.qpid.server.Broker,
> > org.apache.qpid.test.utils.QpidBrokerTestCase,
> > org.apache.qpid.test.utils.InternalBrokerHolder
> >
> > For the creation of queues/exchanges, I suggest us

Re: Corrupt artifacts on Qpid release web page

[Adel Boutros]

Hello Lorenz,


I tried on Windows and 
Linux<http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/binaries/qpid-broker-6.1.1-bin.tar.gz>


Linux:

curl -O 
http://www.apache.org/dyn/closer.lua/qpid/java/6.1.1/qpid-java-6.1.1.tar.gz

tar xfz qpid-java-6.1.1.tar.gz


gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now



Windows (Using B1 archiver):

I can extract qpid-java-6.1.1.tar.gz to qpid-java-6.1.1.tar
I cannot extract qpid-java-6.1.1.tar (Archive is broker or damaged)



Regards,

Adel


From: Lorenz Quack <quack.lor...@gmail.com>
Sent: Monday, March 20, 2017 10:13:59 AM
To: users@qpid.apache.org
Subject: Re: Corrupt artifacts on Qpid release web page

Hi,

I just tried the source bundle of the "Qpid for Java 6.1.1," release
without issues.
I used the command
$ tar xfz qpid-java-6.1.1.tar.gz
to unpack the source bundle.

With which artefacts do you experience problems specifically?
What tools are you using to extract the files?
Windows, Linux?

Kind regards,
Lorenz


On 20/03/17 09:05, Adel Boutros wrote:
> Hello,
>
>
> It seems all ".tar" artifacts are corrupt when accessed from 
> https://qpid.apache.org/releases.
>
>
> I can download all ".tar.gz" and unzip them. However, I cannot extract the 
> ".tar".
>
>
> Are you aware of such issue?
>
>
> Regards,
>
> Adel
>
>


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Corrupt artifacts on Qpid release web page

[Adel Boutros]

Hello,


It seems all ".tar" artifacts are corrupt when accessed from 
https://qpid.apache.org/releases.


I can download all ".tar.gz" and unzip them. However, I cannot extract the 
".tar".


Are you aware of such issue?


Regards,

Adel

Re: [Qpid Broker - 6.0.4] Junit testable?

[Adel Boutros]

Indeed, most users will most probably inject a JMS connection using Spring 
annotations. So testing it against an easy to embedd broker would be highly 
appreciated because Spring already provides a lot of helpers in testing.


The problem is that each broker respects the specifications the way it say it 
fit. We had issues with ActiveMQ when configuring topic linked to queues with 
advanced filtering. This is why embeddable broker should be as close as 
possible to the production broker to avoid skipping some bugs or unsupported 
cases.


@Keith,

Indeed we could configure queues using REST but then again we need 2 things:

* Know the port

* Develop a Java like API for rest operations (Not all users knows the REST 
calls of the broker


This is why I was saying the Qpid Broker is not very friendly to use with JMS.


I will give a look at the classes you mentioned.


Regards,

Adel


From: Dan Langford <danlangf...@gmail.com>
Sent: Friday, March 17, 2017 3:46:46 PM
To: keith.w...@gmail.com; users@qpid.apache.org
Subject: Re: [Qpid Broker - 6.0.4] Junit testable?

You already mentioned HornetQ I would also toss out there ActiveMQ as one
that is fantastic at embedding. In my Java projects I code to JMS and in
Unit tests I mock out JMS apis because I am just testing MY code. Sometimes
it's just easier or a more thorough test to include a broker especially
since so much config is moving into Java code these days (spring JMS
annotations) and for those I use ActiveMQ embedded. Once I get up to
integration type tests we have all of our code tests against a few non-prod
Qpid servers we have. We actually have Dev, Test, Stage, Load lanes before
getting up into prod. That's probably more lanes than most people need but
we have 80-100 little tiny applications that we are regularly working on so
those lanes help us manage their progression towards prod.

Maybe if you mocked JMS, used an embedded broker that implements AMQP, and
then set up a Staging Qpid server that would give you the confidence you
need to advance to Production


On Fri, Mar 17, 2017 at 8:27 AM Keith W <keith.w...@gmail.com> wrote:

> Hi Adel
>
> There is a recognition that the embed-ability of the Qpid Broker for
> Java is not what it should be.   We have been making incremental
> improvements with each major release but things still aren't ideal
> state.
>
> For the dynamically bound port number, QPID-7597 changes the Broker so
> that it is available from the model:  Port#getBoundPort().  This will
> be part of the next major release.  As things stand in 6.0,
> unfortunately, there is no clean way to discover the actual bound
> port.  The best you could do it scrape the log, or intercept the event
> logging so pull out the bound port number for AMQP and HTTP, neither
> of which are clean I know.  The classes to look at are:
> org.apache.qpid.server.Broker,
> org.apache.qpid.test.utils.QpidBrokerTestCase,
> org.apache.qpid.test.utils.InternalBrokerHolder
>
> For the creation of queues/exchanges, I suggest using the REST API to
> create the objects.  This is a public API and will be maintained going
> forwards.  There is REST API summary documentation in the docbook.
>
>
> http://qpid.apache.org/releases/qpid-java-6.0.6/java-broker/book/Java-Broker-Management-Channel-REST-API.html
>
> There is some online documentation for the REST API available from the
> Web Management Console (API link, menu at top right).  Firebug within
> Firefox has a neat feature to give you a cURL command line for network
> requests that have been sent by the browser.  You can use this as a
> quick way to get a curl command line for an action corresponding you
> have just performed interactively.  The API is pretty simple.
>
> The next major release (v7.0) will include support for AMQP
> Management.  This will allow you to fully manage the Broker from an
> AMQP messaging connection. You will be able to use this to fully
> configure the Broker from say, a JMS connection.  I expect this will
> become our recommendation.
>
> Hope this helps.
>
>
>
> On 17 March 2017 at 12:41, Adel Boutros <adelbout...@live.com> wrote:
> > Hello Robbie,
> >
> > Can you please provide a simple example?
> >
> > Regards,
> > Adel
> > 
> > From: Robbie Gemmell <robbie.gemm...@gmail.com>
> > Sent: Friday, March 17, 2017 12:57:59 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Broker - 6.0.4] Junit testable?
> >
> > On 16 March 2017 at 18:01, Adel Boutros <adelbout...@live.com> wrote:
> >> Hello,
> >>
> >>
> >> As we are currently deploying a messaging solution based on the Java
> Broker, we have tried to start a broker from a Junit test a

Re: [Qpid Broker - 6.0.4] Junit testable?

[Adel Boutros]

Hello Robbie,

Can you please provide a simple example?

Regards,
Adel

From: Robbie Gemmell <robbie.gemm...@gmail.com>
Sent: Friday, March 17, 2017 12:57:59 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Broker - 6.0.4] Junit testable?

On 16 March 2017 at 18:01, Adel Boutros <adelbout...@live.com> wrote:
> Hello,
>
>
> As we are currently deploying a messaging solution based on the Java Broker, 
> we have tried to start a broker from a Junit test and it is not very 
> straightforward as the configuration part is a bit difficult. Of course here 
> we are talking about Component Based Testing and Integration Testing to allow 
> clients to test their code before deploying it.
>
>
> Some of the pain points when using org.apache.qpid.server.Broker:
>
>   *   If port 0 is specified, I have no way to get the actual port allocated
>   *   I need a json config file to configure queues, topics (There is no Java 
> Api for it directly)
>

It might not be as easy as would be desired, but the brokers own test
suite creates queues at runtime (using its HTTP or AMQP management
support) and as far as I know also starts brokers on 'port 0' these
days. Perhaps something to look at.

> Another team had tested HornetQ[1] which seems to be more adapted to embedded 
> testing. However as our production broker will be Qpid Java Broker, we would 
> like our tests to be as close as possible to production.
>
> So my questions are:
>
> * Is there currently a way to use an embedded Java Broker easily configurable 
> in a Junit test?
> * If not, what would be required to provide such easibility?
>
> [1]: 
> http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/embedding-hornetq.html
>
> Regards,
> Adel
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [qpid-proton-cpp] default_container does not implement thread safety at all?

[Adel Boutros]

Hello,

As Alan said, we have for example "abused" the schedule in C++. Today we run 
the container on another thread and we have a shared queue between the 
container threads and the other threads. We call schedule very frequently with 
a delay of 0. Whenever the container thread wakes, it checks the queue to send 
events then calls schedule again. The access to the queue is protected by locks.

The downside is that the container thread abuses a full CPU but we can limit 
this by using a delay of higher than 0 on schedule.

Regards,
Adel


From: Alan Conway 
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
> 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 the above that's supposed to
> be a
> thread safe implementation of a thread pool running a bunch of
> containers.
>
> But after "grep inject" and carefully sifting through the results, it
> seems
> that after some indirection it all ends up calling
>
> // FIXME aconway 2016-06-07: this is not thread safe. It is
> sufficient for
> using
> // default_container::schedule() inside a handler but not for
> inject() from
> // another thread.
> bool event_loop::impl::inject(void_function0& f) {
> try { f(); } catch(...) {}
> return true;
> }
>
> What the hell? Blank exception suppression is just the icing on the
> cake,
> nothing here even resembles doing the actual hard thing: telling the
> reactor to inject a new custom event in a threadsafe manner.

Guilty as charged mlud. This was work in progress when we started to
redo the guts in a more profound way. The Real Thing is coming - it is
available in C now as pn_proactor and the C++ binding is being
refactored on top of it.

> Am I missing something obvious, or is the documentation there, and in
> other
> places, and the example, chemically pure wishful thinking, like, it
> would
> be pretty nice if we supported multithreading, and it would work in
> such
> and such ways then, but unfortunately we don't, as a matter of fact?

The state of the release is probably not clearly documented: the C++ MT
interfaces *allow* you to build an MT app that replaces the
proton::container (as demoed in the mt_broker) BUT the
proton::container itself is still not multithreaded. It has a
compatible API because it will be in future.

> If so, maybe you gals and guys should fix the documentation, and not
> just
> with "experimental" but with "DOESN'T WORK AT ALL" prominent on the
> page?

I agree the doc is not clear, next release it should work as expected
an not as obscurely caveatted.

> On more constructive notes:
>
> 1) do people maybe use some custom containers, similar to the
> epoll_container in the examples (which doesn't support schedule()
> though, I
> have to point out)? If so, I much desire to see one.

Yes, but the plan is to fix the non-custom container to be fully
thread-safe so you don't have to unless you have special needs. You can
also implement directly in C if you have very special needs.

> 2) why do you attempt to bolt on your event_loop thing to Connection
> and
> below when the only thing that has the run() method is Container,
> therefore
> that's the scope that any worker thread would have? It's the
> Container that
> should have the inject() method. Underlying C API notwithstanding.

Nope: the threading model is seralized-per-connection, so functions
that operate only on connection state and are triggered from an event
handler don't need to be locked. Only interactions that cross
connections (e.g. one connection queues something a subscriber on
another connection needs to wake up) need sync. This is demonstrated
with the mt_broker stuff. That's why injecting is per-connection.

> 3) What's the best way forward if I really have to have a threadsafe
> container that I can inject some event into threadsafely:

The example demonstrates how you can do it, but is incomplete as you
point out. Soon it will be built in.

>   3a) does the C API support thread safety? Like, the whole problem
> is
> touching the reactor's job queue or whatever it has with taking an
> appropriate lock, and it must take that same lock itself for it to
> work.

It does now, see the pn_proactor, there are examples. The C reactor is
fundamentally and forever thread-unsafe and horribly broken in all ways
with respect to concurrency. We started to introduce MT at the C++
layer and work around the reactor - proton::container lagged because it
is so tied to the reactor.

Finally we decided to replace the pn_reactor entirely with the
pn_proactor in C - this is 

Re: [Java Broker] Port 0 range

[Adel Boutros]

Hello Rob,


I think I wasn't clear enough. Sorry for that.


As referenced here[1], there are registered ports which are dynamic ports 
however they identify a know service (5672 is one of them).

What I am talking about are private dynamic ports (ephemeral ports) which are 
not registered and to be used internally.


As this is not a requirement useful for all users of the Broker, I was 
wondering if there was a way to specify a certain port range for the broker to 
get an available port from it and which is a lot more restrictive than the full 
dynamic range.


[1]: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers



From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Tuesday, March 14, 2017 5:25:56 PM
To: users@qpid.apache.org
Subject: Re: [Java Broker] Port 0 range

So, the Broker is simply using the Java mechanism... and the Java mechanism
is (I presume) just obeying the settings in your operating system.  Which
operating system are you seeing the broker pick "low" ports on, and how is
that operating system configured with respect to the "dynamic" port
range[1]?  What sort of "low" numbers are you getting... which operating
system are you seeing this on... and does the port number you are seeing
lay outside the OS settings for dynamic port assignment?

-- Rob

[1] According to this (
http://stackoverflow.com/questions/913501/how-to-let-kernel-choose-a-port-number-in-the-range-1024-5000-in-tcp-socket-pr)
StackOverflow question, the following commands can be used to get the
operating system settings:

Linux:
  cat /proc/sys/net/ipv4/ip_local_port_range
Windows:
  netsh int ipv4 show dynamicport tcp
OS X:
  sysctl net.inet.ip.portrange.first net.inet.ip.portrange.last
Solaris:
  /usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port

On 14 March 2017 at 16:56, Adel Boutros <adelbout...@live.com> wrote:

> Hello,
>
>
> We are asked to deploy broker on random ports. So we thought about using
> Port 0 and let the Broker find available ports.
>
> This works as expected however we have a concern with the port range.
>
>
> It seems by default Java will take any port outside the well known ports
> and assign it. However, in large environments, services are requested to
> use private/dynamic ports (range 49152 to 65535 as specified by the
> Internet Assigned Numbers Authority).
>
>
> So I was wondering if there was a way to make the broker respect this port
> range when it is passed a port value of 0?
>
>
> Maybe allow the user to pass a property defining the range of ports
> available.
>
>
> What do you think?
>
>
> Regards,
>
> Adel
>

[Java Broker] Port 0 range

[Adel Boutros]

Hello,


We are asked to deploy broker on random ports. So we thought about using Port 0 
and let the Broker find available ports.

This works as expected however we have a concern with the port range.


It seems by default Java will take any port outside the well known ports and 
assign it. However, in large environments, services are requested to use 
private/dynamic ports (range 49152 to 65535 as specified by the Internet 
Assigned Numbers Authority).


So I was wondering if there was a way to make the broker respect this port 
range when it is passed a port value of 0?


Maybe allow the user to pass a property defining the range of ports available.


What do you think?


Regards,

Adel

Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux

[Adel Boutros]

Great!

I had stumbled on this issue by coincidence while debugging another one on 
Solaris.

It might be useful to execute the unit tests multiple times on the CI to detect 
such random issues. It's what we are currently doing and it had revealed some 
bugs for us over time.

Regards,
Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Friday, March 3, 2017 8:16:15 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux

Hi Adel,
We found the reason the test was failing. I have entered a JIRA for this -

https://issues.apache.org/jira/browse/DISPATCH-646

The fix to this problem is not straightforward. We are still discussing this. 
This only affects drain processing on link routes. This test can be reproduced 
more frequently if you remove 'workerThreads': 1 from system_test.py which will 
default workerThreads to 4.

Thanks for bringing this to our attention.

Thanks.

- Original Message -----
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Thursday, March 2, 2017 10:48:04 AM
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
> "system_tests_link_routes" on Linux
>
> Great!
>
>
> Good luck [?]
>
> Adel
>
> 
> From: Ganesh Murthy <gmur...@redhat.com>
> Sent: Thursday, March 2, 2017 4:18:54 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> "system_tests_link_routes" on Linux
>
> Hi Adel,
>Luckily, I was able to reproduce your problem locally. I will keep you
>posted on my findings.
> Thanks.
>
> - Original Message -
> > From: "Adel Boutros" <adelbout...@live.com>
> > To: users@qpid.apache.org
> > Sent: Wednesday, March 1, 2017 3:11:59 PM
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> > Hello Ganesh,
> >
> >
> > It seems that "zip" files are not allowed and thus my mail is never getting
> > delivered.
> >
> >
> > You can get it from here: http://www.filedropper.com/test_210
> >
> >
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Adel Boutros
> > Sent: Wednesday, March 1, 2017 9:09:29 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> >
> > It seems for some reason my mail wasn't sent. I am re-attaching the output
> > here.
> >
> >
> > Can you confirm you got it now?
> >
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Ganesh Murthy <gmur...@redhat.com>
> > Sent: Wednesday, March 1, 2017 9:05:43 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> > Hi Adel,
> >I sent you a subsequent email asking you for the log files. Did you
> >already respond to that email? For some reason, I am not seeing your
> >response. I see only your first response where you attached the output
> >of
> >PN_TRACE_FRM=1
> >
> > Can you please resend the log files?
> >
> > Sorry, Thanks.
> >
> > - Original Message -
> > > From: "Adel Boutros" <adelbout...@live.com>
> > > To: users@qpid.apache.org
> > > Sent: Wednesday, March 1, 2017 2:55:21 PM
> > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > > "system_tests_link_routes" on Linux
> > >
> > > Hello Ganesh,
> > >
> > >
> > > Did you have any luck with what I sent you?
> > >
> > >
> > > Regards,
> > >
> > > Adel
> > >
> > > 
> > > From: Adel Boutros
> > > Sent: Wednesday, March 1, 2017 9:56:44 AM
> > > To: users@qpid.apache.org
> > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > > "system_tests_link_routes" on Linux
> > >
> > >
> > > No worries, it's ok :)
> > >
> > >
> > > You will find attached the requested content.
> > >
> > >
> > > Regards,
> > >
> > > Adel
> > >
> > > __

Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux

[Adel Boutros]

Great!


Good luck [?]

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Thursday, March 2, 2017 4:18:54 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux

Hi Adel,
   Luckily, I was able to reproduce your problem locally. I will keep you 
posted on my findings.
Thanks.

- Original Message -----
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Wednesday, March 1, 2017 3:11:59 PM
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
> "system_tests_link_routes" on Linux
>
> Hello Ganesh,
>
>
> It seems that "zip" files are not allowed and thus my mail is never getting
> delivered.
>
>
> You can get it from here: http://www.filedropper.com/test_210
>
>
>
> Regards,
>
> Adel
>
> 
> From: Adel Boutros
> Sent: Wednesday, March 1, 2017 9:09:29 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> "system_tests_link_routes" on Linux
>
>
> It seems for some reason my mail wasn't sent. I am re-attaching the output
> here.
>
>
> Can you confirm you got it now?
>
>
> Regards,
>
> Adel
>
> 
> From: Ganesh Murthy <gmur...@redhat.com>
> Sent: Wednesday, March 1, 2017 9:05:43 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> "system_tests_link_routes" on Linux
>
> Hi Adel,
>I sent you a subsequent email asking you for the log files. Did you
>already respond to that email? For some reason, I am not seeing your
>response. I see only your first response where you attached the output of
>PN_TRACE_FRM=1
>
> Can you please resend the log files?
>
> Sorry, Thanks.
>
> - Original Message -
> > From: "Adel Boutros" <adelbout...@live.com>
> > To: users@qpid.apache.org
> > Sent: Wednesday, March 1, 2017 2:55:21 PM
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> > Hello Ganesh,
> >
> >
> > Did you have any luck with what I sent you?
> >
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Adel Boutros
> > Sent: Wednesday, March 1, 2017 9:56:44 AM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> >
> > No worries, it's ok :)
> >
> >
> > You will find attached the requested content.
> >
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Ganesh Murthy <gmur...@redhat.com>
> > Sent: Tuesday, February 28, 2017 8:24:20 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> > Hi Adel,
> >Thanks for sending the trace. I realized that what I actually wanted to
> >see is the log files of all routers so I can get a complete view of the
> >traffic between the routers. Can you please zip up the contents of the
> >    
> > /build/system_test.dir/system_tests_link_routes/LinkRouteTest/setUpClass
> >folder and send it?
> >
> > Before you zip up the contents of that folder, please delete all the
> > contents
> > of the folder and then run only the relevant test like this -
> >
> > /usr/bin/python "/build/tests/run.py" "-m"
> > "unittest" "-v"
> > "system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages"
> >
> > (this way, the log files will only have the trace from the relevant test)
> >
> > Thanks much.
> >
> > - Original Message -
> > > From: "Adel Boutros" <adelbout...@live.com>
> > > To: users@qpid.apache.org
> > > Sent: Tuesday, February 28, 2017 1:08:53 PM
> > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > > "system_tests_link_routes" on Linux
> > >
> > >
> > >
> > > You will find attached the result of the below command.
> > >
> > >
> > >
> > >
> > > Adel
> > >
> > > From: Ganesh Murthy <gmur...@redhat.com>
> > > Sent: Tuesd

Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux

[Adel Boutros]

Hello Ganesh,


It seems that "zip" files are not allowed and thus my mail is never getting 
delivered.


You can get it from here: http://www.filedropper.com/test_210



Regards,

Adel

____
From: Adel Boutros
Sent: Wednesday, March 1, 2017 9:09:29 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux


It seems for some reason my mail wasn't sent. I am re-attaching the output here.


Can you confirm you got it now?


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Wednesday, March 1, 2017 9:05:43 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux

Hi Adel,
   I sent you a subsequent email asking you for the log files. Did you already 
respond to that email? For some reason, I am not seeing your response. I see 
only your first response where you attached the output of PN_TRACE_FRM=1

Can you please resend the log files?

Sorry, Thanks.

----- Original Message -
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Wednesday, March 1, 2017 2:55:21 PM
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
> "system_tests_link_routes" on Linux
>
> Hello Ganesh,
>
>
> Did you have any luck with what I sent you?
>
>
> Regards,
>
> Adel
>
> 
> From: Adel Boutros
> Sent: Wednesday, March 1, 2017 9:56:44 AM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> "system_tests_link_routes" on Linux
>
>
> No worries, it's ok :)
>
>
> You will find attached the requested content.
>
>
> Regards,
>
> Adel
>
> 
> From: Ganesh Murthy <gmur...@redhat.com>
> Sent: Tuesday, February 28, 2017 8:24:20 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> "system_tests_link_routes" on Linux
>
> Hi Adel,
>Thanks for sending the trace. I realized that what I actually wanted to
>see is the log files of all routers so I can get a complete view of the
>traffic between the routers. Can you please zip up the contents of the
>
> /build/system_test.dir/system_tests_link_routes/LinkRouteTest/setUpClass
>folder and send it?
>
> Before you zip up the contents of that folder, please delete all the contents
> of the folder and then run only the relevant test like this -
>
> /usr/bin/python "/build/tests/run.py" "-m"
> "unittest" "-v"
> "system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages"
>
> (this way, the log files will only have the trace from the relevant test)
>
> Thanks much.
>
> - Original Message -
> > From: "Adel Boutros" <adelbout...@live.com>
> > To: users@qpid.apache.org
> > Sent: Tuesday, February 28, 2017 1:08:53 PM
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> >
> >
> > You will find attached the result of the below command.
> >
> >
> >
> >
> > Adel
> >
> > From: Ganesh Murthy <gmur...@redhat.com>
> > Sent: Tuesday, February 28, 2017 6:51:42 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> > Hi Adel,
> > Can you please run that specific unit test with PN_TRACE_FRM=1 and send the
> > output. This is how you run the specific test -
> >
> > PN_TRACE_FRM=1 /usr/bin/python
> > "/build/tests/run.py"
> > "-m" "unittest" "-v"
> > "system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages"
> >
> > Thanks.
> >
> > - Original Message -
> > > From: "Adel Boutros" <adelbout...@live.com>
> > > To: users@qpid.apache.org
> > > Sent: Tuesday, February 28, 2017 10:20:42 AM
> > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > > "system_tests_link_routes" on Linux
> > >
> > > Hi Ganesh,
> > >
> > >
> > > Yes, I had checked your fix but it doesn't seem to work here. Indeed, the
> > > test is still failing even when timeout is increased to 100.
> > >
> > >
> > > It seems the drain is always only receiving 8 messages ou

Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux

[Adel Boutros]

Hello Ganesh,


Did you have any luck with what I sent you?


Regards,

Adel


From: Adel Boutros
Sent: Wednesday, March 1, 2017 9:56:44 AM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux


No worries, it's ok :)


You will find attached the requested content.


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Tuesday, February 28, 2017 8:24:20 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux

Hi Adel,
   Thanks for sending the trace. I realized that what I actually wanted to see 
is the log files of all routers so I can get a complete view of the traffic 
between the routers. Can you please zip up the contents of the 
/build/system_test.dir/system_tests_link_routes/LinkRouteTest/setUpClass
 folder and send it?

Before you zip up the contents of that folder, please delete all the contents 
of the folder and then run only the relevant test like this -

/usr/bin/python "/build/tests/run.py" "-m" "unittest" 
"-v" 
"system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages"

(this way, the log files will only have the trace from the relevant test)

Thanks much.

- Original Message -
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Tuesday, February 28, 2017 1:08:53 PM
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
> "system_tests_link_routes" on Linux
>
>
>
> You will find attached the result of the below command.
>
>
>
>
> Adel
>
> From: Ganesh Murthy <gmur...@redhat.com>
> Sent: Tuesday, February 28, 2017 6:51:42 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> "system_tests_link_routes" on Linux
> Hi Adel,
> Can you please run that specific unit test with PN_TRACE_FRM=1 and send the
> output. This is how you run the specific test -
>
> PN_TRACE_FRM=1 /usr/bin/python "/build/tests/run.py"
> "-m" "unittest" "-v"
> "system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages"
>
> Thanks.
>
> - Original Message -
> > From: "Adel Boutros" <adelbout...@live.com>
> > To: users@qpid.apache.org
> > Sent: Tuesday, February 28, 2017 10:20:42 AM
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> > Hi Ganesh,
> >
> >
> > Yes, I had checked your fix but it doesn't seem to work here. Indeed, the
> > test is still failing even when timeout is increased to 100.
> >
> >
> > It seems the drain is always only receiving 8 messages out of 10. I didn't
> > check it on the trunk however to see if it is fixed.
> >
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Ganesh Murthy <gmur...@redhat.com>
> > Sent: Tuesday, February 28, 2017 3:58:37 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> > Hi Adel,
> > We did notice the same problem you are seeing and we did end up increasing
> > the timeout from 5 to 10 (although on a different test) as seen in this
> > commit on master branch -
> >
> > https://github.com/apache/qpid-dispatch/commit/5e6b2e65b2ea9614d7619711961d38aceefb49d4
> >
> > Is it correct that even when you increased the timeout to 100, the test
> > still
> > fails randomly?
> >
> > Thanks.
> >
> > - Original Message -
> > > From: "Adel Boutros" <adelbout...@live.com>
> > > To: users@qpid.apache.org
> > > Sent: Tuesday, February 28, 2017 9:00:36 AM
> > > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > > "system_tests_link_routes" on Linux
> > >
> > > I increased the timeout from 5 to 100 and the test which now takes 110
> > > seconds instead of 10 seconds is still failing. After re-checking, the
> > > error
> > > message is actually the same on each failure. I think there is an issue
> > > here.
> > >
> > >
> > > My patch:
> > >
> > >
> > > diff --git a/tests/system_tests_drain_support.py
> > > b/tests/system_tests_drain_support.py
> &

Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux

[Adel Boutros]

You will find attached the result of the below command.


Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Tuesday, February 28, 2017 6:51:42 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux

Hi Adel,
   Can you please run that specific unit test with PN_TRACE_FRM=1 and send the 
output. This is how you run the specific test -

PN_TRACE_FRM=1 /usr/bin/python "/build/tests/run.py" 
"-m" "unittest" "-v" 
"system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages"

Thanks.

- Original Message -
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Tuesday, February 28, 2017 10:20:42 AM
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
> "system_tests_link_routes" on Linux
>
> Hi Ganesh,
>
>
> Yes, I had checked your fix but it doesn't seem to work here. Indeed, the
> test is still failing even when timeout is increased to 100.
>
>
> It seems the drain is always only receiving 8 messages out of 10. I didn't
> check it on the trunk however to see if it is fixed.
>
>
> Regards,
>
> Adel
>
> 
> From: Ganesh Murthy <gmur...@redhat.com>
> Sent: Tuesday, February 28, 2017 3:58:37 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> "system_tests_link_routes" on Linux
>
> Hi Adel,
>We did notice the same problem you are seeing and we did end up increasing
>the timeout from 5 to 10 (although on a different test) as seen in this
>commit on master branch -
>
> https://github.com/apache/qpid-dispatch/commit/5e6b2e65b2ea9614d7619711961d38aceefb49d4
>
> Is it correct that even when you increased the timeout to 100, the test still
> fails randomly?
>
> Thanks.
>
> - Original Message -
> > From: "Adel Boutros" <adelbout...@live.com>
> > To: users@qpid.apache.org
> > Sent: Tuesday, February 28, 2017 9:00:36 AM
> > Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> > I increased the timeout from 5 to 100 and the test which now takes 110
> > seconds instead of 10 seconds is still failing. After re-checking, the
> > error
> > message is actually the same on each failure. I think there is an issue
> > here.
> >
> >
> > My patch:
> >
> >
> > diff --git a/tests/system_tests_drain_support.py
> > b/tests/system_tests_drain_support.py
> > index e4bd2bc..9a4a86f 100644
> > --- a/tests/system_tests_drain_support.py
> > +++ b/tests/system_tests_drain_support.py
> > @@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler):
> >  self.conn.close()
> >
> >  def on_start(self, event):
> > -self.timer = event.reactor.schedule(5, Timeout(self))
> > +self.timer = event.reactor.schedule(100, Timeout(self))
> >  self.conn = event.container.connect(self.address)
> >
> >  # Create a sender and a receiver. They are both listening on the
> >  same address
> >
> >
> > ==
> >
> > Error
> >
> > ===
> >
> >
> > 13: FAIL: test_www_drain_support_all_messages
> > (system_tests_link_routes.LinkRouteTest)
> > 13: --
> > 13: Traceback (most recent call last):
> > 13:   File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line
> > 489, in test_www_drain_support_all_messages
> > 13: self.assertEqual(None, drain_support.error)
> > 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8'
> > 13:
> > 13: --
> > 13: Ran 15 tests in 109.933s
> > 13:
> > 13: FAILED (failures=1)
> > 1/1 Test #13: system_tests_link_routes .***Failed  110.16 sec
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Adel Boutros <adelbout...@live.com>
> > Sent: Tuesday, February 28, 2017 2:47:16 PM
> > To: users@qpid.apache.org
> > Subject: [Qpid Dispatch - 0.7.0] Random failure on unit test
> > "system_tests_link_routes" on Linux
> >
> > Hello,
> >
> >
> > I noticed a random issue with the Dispatch Router 0.7.0 which has a random
> > failure in the test "system_test

Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux

[Adel Boutros]

Hi Ganesh,


Yes, I had checked your fix but it doesn't seem to work here. Indeed, the test 
is still failing even when timeout is increased to 100.


It seems the drain is always only receiving 8 messages out of 10. I didn't 
check it on the trunk however to see if it is fixed.


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Tuesday, February 28, 2017 3:58:37 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux

Hi Adel,
   We did notice the same problem you are seeing and we did end up increasing 
the timeout from 5 to 10 (although on a different test) as seen in this commit 
on master branch -

https://github.com/apache/qpid-dispatch/commit/5e6b2e65b2ea9614d7619711961d38aceefb49d4

Is it correct that even when you increased the timeout to 100, the test still 
fails randomly?

Thanks.

- Original Message -----
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Tuesday, February 28, 2017 9:00:36 AM
> Subject: Re: [Qpid Dispatch - 0.7.0] Random failure on unit test 
> "system_tests_link_routes" on Linux
>
> I increased the timeout from 5 to 100 and the test which now takes 110
> seconds instead of 10 seconds is still failing. After re-checking, the error
> message is actually the same on each failure. I think there is an issue
> here.
>
>
> My patch:
>
>
> diff --git a/tests/system_tests_drain_support.py
> b/tests/system_tests_drain_support.py
> index e4bd2bc..9a4a86f 100644
> --- a/tests/system_tests_drain_support.py
> +++ b/tests/system_tests_drain_support.py
> @@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler):
>  self.conn.close()
>
>  def on_start(self, event):
> -self.timer = event.reactor.schedule(5, Timeout(self))
> +self.timer = event.reactor.schedule(100, Timeout(self))
>  self.conn = event.container.connect(self.address)
>
>  # Create a sender and a receiver. They are both listening on the
>  same address
>
>
> ==
>
> Error
>
> ===
>
>
> 13: FAIL: test_www_drain_support_all_messages
> (system_tests_link_routes.LinkRouteTest)
> 13: --
> 13: Traceback (most recent call last):
> 13:   File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line
> 489, in test_www_drain_support_all_messages
> 13: self.assertEqual(None, drain_support.error)
> 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8'
> 13:
> 13: --
> 13: Ran 15 tests in 109.933s
> 13:
> 13: FAILED (failures=1)
> 1/1 Test #13: system_tests_link_routes .***Failed  110.16 sec
>
> Regards,
>
> Adel
>
> 
> From: Adel Boutros <adelbout...@live.com>
> Sent: Tuesday, February 28, 2017 2:47:16 PM
> To: users@qpid.apache.org
> Subject: [Qpid Dispatch - 0.7.0] Random failure on unit test
> "system_tests_link_routes" on Linux
>
> Hello,
>
>
> I noticed a random issue with the Dispatch Router 0.7.0 which has a random
> failure in the test "system_tests_link_routes".
>
> I launch the same test 10 times, it fails randomly (Failure occurs at the 4th
> or 5th run) but always with a similar error. It seems the timeout of 5
> milliseconds is not enough especially on slow machines.
>
>
> I had submitted a patch for a similar task
> (https://issues.apache.org/jira/browse/DISPATCH-627)
>
>
> Can you please confirm?
>
>
> Regards,
>
> Adel
>
>
> 13: ==
> 13: FAIL: test_www_drain_support_all_messages
> (system_tests_link_routes.LinkRouteTest)
> 13: --
> 13: Traceback (most recent call last):
> 13:   File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line
> 489, in test_www_drain_support_all_messages
> 13: self.assertEqual(None, drain_support.error)
> 13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8'
>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Patch + jira vs pull request

[Adel Boutros]

Thank you Ganesh for the explanation!


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Tuesday, February 28, 2017 3:31:57 PM
To: users@qpid.apache.org
Subject: Re: Patch + jira vs pull request

A few days back, I had emailed Travis support and asked them why the builds 
were taking too long to start. This is what they said -

"I've been taking a look at the logs and it appears that at the time when your 
build #199359621 was triggered, the Apache organization was running at 
capacity, and this delayed the start time of the jobs.

At the moment, I see that the organization is running at capacity too and it 
has some backlog of pending jobs waiting to start. To help with this high 
activity peak, I've boosted Apache's capacity from 30 to 50 concurrent jobs for 
the next 4 hours."

So, when you submitted the pull request, it simply looks like Travis was 
running at full capacity for Apache. It should come thru as soon as the backlog 
is cleared.


Thanks.

- Original Message -----
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Tuesday, February 28, 2017 9:10:26 AM
> Subject: Re: Patch + jira vs pull request
>
> Hello,
>
>
> I was testing this morning the pull request mechanism. I was able to perform
> the pull request however it seems Travis has not built it yet.
>
> Is there a way to know what's blocking it?
> (https://travis-ci.org/apache/qpid-dispatch/builds/206144819)
>
>
> Regards,
>
> Adel
>
> 
> From: Robbie Gemmell <robbie.gemm...@gmail.com>
> Sent: Monday, February 6, 2017 4:08:13 PM
> To: users@qpid.apache.org
> Subject: Re: Patch + jira vs pull request
>
> As an aside, for anyone else wanting to do this type of thing, I used
> this to add a remote called 'github' to my existing checkout and make
> the PRs available at ref github/pr/:
>
> git remote add github https://github.com/apache/qpid-java.git
> git config --local --add remote.github.fetch
> '+refs/pull/*/head:refs/remotes/github/pr/*'
> git fetch --all
>
> To use a different name for the remote, find/replace instances of
> github other than in the mirror URL with your chosen remote name. To
> use another repo, change the name in the URL.
>
> Robbie
>
> On 31 January 2017 at 12:26, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> > This is now enabled, see
> > https://issues.apache.org/jira/browse/QPID-7650 and
> > https://github.com/apache/qpid-java/pull/5 as example.
> >
> > Note that the mails to the dev@ list were still not seen, as something
> > seems to be wrong with the list, or at least JIRA. No mails from JIRA
> > are arriving, even though I have been receiving the matching/duplicate
> > mails sent directly to me. Raised as
> > https://issues.apache.org/jira/browse/INFRA-13432 after chatting to
> > infra, likely related to the very recent JIRA upgrade. I'll give the
> > PR thing another check once its clearer what the issues are.
> >
> > Also, while the process of closing the PR worked fine, it did take a
> > good 20+mins for the commit to make it to the github mirror (via the
> > asf git mirror, via svn) and close it, as opposed to the near instant
> > updates normally seen when using the git repositories.
> >
> > Robbie
> >
> > On 30 January 2017 at 13:19, Robbie Gemmell <robbie.gemm...@gmail.com>
> > wrote:
> >> Saying that made me look, and it seems like the GitHub integration is
> >> indeed not enabled on the apache/qpid-java mirror. There are a few old
> >> open Pull Requests and one test PR open+closed (nice account Lorenz
> >> :P), none of which have been visible on the list. I raised
> >> https://issues.apache.org/jira/browse/INFRA-13422 to get the GitHub
> >> mails/JIRA comments integration enabled for the repo.
> >>
> >> Robbie
> >>
> >> On 30 January 2017 at 12:28, Robbie Gemmell <robbie.gemm...@gmail.com>
> >> wrote:
> >>> JIRA+PR or JIRA+patch, either approach is fine and works out largely
> >>> the same for us in the end (almost identical if you really want, since
> >>> you can get a patch by adding .patch to github pr/diff/commit URLs).
> >>>
> >>> Assuming the 'GitHub integration' stuff is enabled (and if it isn't,
> >>> that would be an oversight) on the particular GitHub mirror in
> >>> question, raising a PR generates a mail to the dev@ mailing list, and
> >>> if the JIRA key is in the PR title (e.g "QPID-1234:short description")
> >>> then a comment will also be placed on th

Re: Patch + jira vs pull request

[Adel Boutros]

Hello,


I was testing this morning the pull request mechanism. I was able to perform 
the pull request however it seems Travis has not built it yet.

Is there a way to know what's blocking it? 
(https://travis-ci.org/apache/qpid-dispatch/builds/206144819)


Regards,

Adel


From: Robbie Gemmell <robbie.gemm...@gmail.com>
Sent: Monday, February 6, 2017 4:08:13 PM
To: users@qpid.apache.org
Subject: Re: Patch + jira vs pull request

As an aside, for anyone else wanting to do this type of thing, I used
this to add a remote called 'github' to my existing checkout and make
the PRs available at ref github/pr/:

git remote add github https://github.com/apache/qpid-java.git
git config --local --add remote.github.fetch
'+refs/pull/*/head:refs/remotes/github/pr/*'
git fetch --all

To use a different name for the remote, find/replace instances of
github other than in the mirror URL with your chosen remote name. To
use another repo, change the name in the URL.

Robbie

On 31 January 2017 at 12:26, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> This is now enabled, see
> https://issues.apache.org/jira/browse/QPID-7650 and
> https://github.com/apache/qpid-java/pull/5 as example.
>
> Note that the mails to the dev@ list were still not seen, as something
> seems to be wrong with the list, or at least JIRA. No mails from JIRA
> are arriving, even though I have been receiving the matching/duplicate
> mails sent directly to me. Raised as
> https://issues.apache.org/jira/browse/INFRA-13432 after chatting to
> infra, likely related to the very recent JIRA upgrade. I'll give the
> PR thing another check once its clearer what the issues are.
>
> Also, while the process of closing the PR worked fine, it did take a
> good 20+mins for the commit to make it to the github mirror (via the
> asf git mirror, via svn) and close it, as opposed to the near instant
> updates normally seen when using the git repositories.
>
> Robbie
>
> On 30 January 2017 at 13:19, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
>> Saying that made me look, and it seems like the GitHub integration is
>> indeed not enabled on the apache/qpid-java mirror. There are a few old
>> open Pull Requests and one test PR open+closed (nice account Lorenz
>> :P), none of which have been visible on the list. I raised
>> https://issues.apache.org/jira/browse/INFRA-13422 to get the GitHub
>> mails/JIRA comments integration enabled for the repo.
>>
>> Robbie
>>
>> On 30 January 2017 at 12:28, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
>>> JIRA+PR or JIRA+patch, either approach is fine and works out largely
>>> the same for us in the end (almost identical if you really want, since
>>> you can get a patch by adding .patch to github pr/diff/commit URLs).
>>>
>>> Assuming the 'GitHub integration' stuff is enabled (and if it isn't,
>>> that would be an oversight) on the particular GitHub mirror in
>>> question, raising a PR generates a mail to the dev@ mailing list, and
>>> if the JIRA key is in the PR title (e.g "QPID-1234:short description")
>>> then a comment will also be placed on the JIRA for the open/close and
>>> any PR comments. The JIRA key should also be included in the commit so
>>> that once merged the JIRA is updated with details of the actual commit
>>> (see existing commits/JIRAs). We cant click the typical 'merge pr'
>>> button on GitHub at this time, as the mirrors are read only, but we
>>> can add the mirrors as remotes for our existing checkouts and
>>> merge+push PR commits to the source repo which then get mirrored
>>> similarly. PRs are marked merged automatically if their commit history
>>> became the unmodified head at the time of merge, but more safely can
>>> be closed out by a commit (either the specific one with the changes,
>>> or a merge commit introducing the original, or just an empty commit)
>>> containing a "This closes #" message somewhere in their log. The
>>> PR process for the ASF's GitHub mirrors works essentially the same for
>>> the svn based repos as it does for the Git based repos (asuming you
>>> are actually using git-svn, which I believe many/most folks are?).
>>>
>>> Robbie
>>>
>>> On 30 January 2017 at 11:51, Lorenz Quack <quack.lor...@gmail.com> wrote:
>>>> I think it is different for different components of Qpid.
>>>>
>>>> The Qpid broker for Java for example has not migrated its main repository 
>>>> to
>>>> git.
>>>> Also the GitHub mirror is treated as read-only. And it is quite possible
>&g

Re: [Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux

[Adel Boutros]

I increased the timeout from 5 to 100 and the test which now takes 110 seconds 
instead of 10 seconds is still failing. After re-checking, the error message is 
actually the same on each failure. I think there is an issue here.


My patch:


diff --git a/tests/system_tests_drain_support.py 
b/tests/system_tests_drain_support.py
index e4bd2bc..9a4a86f 100644
--- a/tests/system_tests_drain_support.py
+++ b/tests/system_tests_drain_support.py
@@ -46,7 +46,7 @@ class DrainMessagesHandler(MessagingHandler):
 self.conn.close()

 def on_start(self, event):
-self.timer = event.reactor.schedule(5, Timeout(self))
+self.timer = event.reactor.schedule(100, Timeout(self))
 self.conn = event.container.connect(self.address)

 # Create a sender and a receiver. They are both listening on the same 
address


==

Error

===


13: FAIL: test_www_drain_support_all_messages 
(system_tests_link_routes.LinkRouteTest)
13: --
13: Traceback (most recent call last):
13:   File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line 489, 
in test_www_drain_support_all_messages
13: self.assertEqual(None, drain_support.error)
13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8'
13:
13: --
13: Ran 15 tests in 109.933s
13:
13: FAILED (failures=1)
1/1 Test #13: system_tests_link_routes .***Failed  110.16 sec

Regards,

Adel

____
From: Adel Boutros <adelbout...@live.com>
Sent: Tuesday, February 28, 2017 2:47:16 PM
To: users@qpid.apache.org
Subject: [Qpid Dispatch - 0.7.0] Random failure on unit test 
"system_tests_link_routes" on Linux

Hello,


I noticed a random issue with the Dispatch Router 0.7.0 which has a random 
failure in the test "system_tests_link_routes".

I launch the same test 10 times, it fails randomly (Failure occurs at the 4th 
or 5th run) but always with a similar error. It seems the timeout of 5 
milliseconds is not enough especially on slow machines.


I had submitted a patch for a similar task 
(https://issues.apache.org/jira/browse/DISPATCH-627)


Can you please confirm?


Regards,

Adel


13: ==
13: FAIL: test_www_drain_support_all_messages 
(system_tests_link_routes.LinkRouteTest)
13: --
13: Traceback (most recent call last):
13:   File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line 489, 
in test_www_drain_support_all_messages
13: self.assertEqual(None, drain_support.error)
13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8'

[Qpid Dispatch - 0.7.0] Random failure on unit test "system_tests_link_routes" on Linux

[Adel Boutros]

Hello,


I noticed a random issue with the Dispatch Router 0.7.0 which has a random 
failure in the test "system_tests_link_routes".

I launch the same test 10 times, it fails randomly (Failure occurs at the 4th 
or 5th run) but always with a similar error. It seems the timeout of 5 
milliseconds is not enough especially on slow machines.


I had submitted a patch for a similar task 
(https://issues.apache.org/jira/browse/DISPATCH-627)


Can you please confirm?


Regards,

Adel


13: ==
13: FAIL: test_www_drain_support_all_messages 
(system_tests_link_routes.LinkRouteTest)
13: --
13: Traceback (most recent call last):
13:   File "/qpid-dispatch-0.7.0/tests/system_tests_link_routes.py", line 489, 
in test_www_drain_support_all_messages
13: self.assertEqual(None, drain_support.error)
13: AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 8'

Re: [Qpid Dispatch] Message States on Web Management Console of Qpid Java Broker

[Adel Boutros]

I have to admit, the different between LinkRoutes and AutoLinks was not clear 
to me.


Do you mind stating the advantages and drawbacks of each? (We are mainly 
interested in the load balancing and performance aspects)


Regards,

Adel


From: Ted Ross <tr...@redhat.com>
Sent: Friday, February 24, 2017 12:12:29 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Message States on Web Management Console of Qpid 
Java Broker

Adel,

I don't know what your use case is, but at the risk of creating more
confusion I will mention that using link-routing to a broker through a
router network has very different behavior.

With link-routing, there is no prefetch and the routers don't do any
load balancing.  The links are attached from consumer to broker through
the router network.  Credit is handled by each side normally.  If the
consumer detaches or drops, all of its in-flight deliveries will be
released to the broker and held there until another consumer appears.

-Ted

On 02/24/2017 10:58 AM, Adel Boutros wrote:
> That's perfectly clear! In our use cases, the default behavior will be enough 
> for now.
>
>
> Thanks,
>
> Adel
>
> 
> From: Ted Ross <tr...@redhat.com>
> Sent: Friday, February 24, 2017 11:52:37 AM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Message States on Web Management Console of Qpid 
> Java Broker
>
> Sorry Adel, I should have been more clear.  I meant that it might be
> possible to design and code a new feature for the router to allow it to
> revoke and release when the last consumer is gone from the network.
>
> I don't think this would be the desirable default behavior however.  It
> would only be useful if there were consumers on the broker that access
> the broker directly and not through the router network.  If all the
> consumers access the broker through the routers, the current behavior is
> more efficient.
>
> -Ted
>
> On 02/24/2017 09:01 AM, Adel Boutros wrote:
>> Thank you Ted for your clarifications. However, there is still something 
>> confusing:
>>
>>
>> You said "It might be possible for the router to revoke credit and release 
>> all of its prefetched deliveries once it becomes aware that there are no 
>> more consumers in the network".
>>
>>
>> However, this is not what we are experiencing as the dispatch router is 
>> still fetching newly sent messages after all consumers have been closed on 
>> the dispatch router (So no consumers are connected to it) which contradicts 
>> the previous hypothesis, no?
>>
>>
>> What triggers the "it might"?
>>
>>
>> Regards,
>>
>> Adel
>>
>> ____
>> From: Ted Ross <tr...@redhat.com>
>> Sent: Thursday, February 23, 2017 9:48:32 PM
>> To: users@qpid.apache.org
>> Subject: Re: [Qpid Dispatch] Message States on Web Management Console of 
>> Qpid Java Broker
>>
>>
>> On 02/23/2017 05:52 PM, Adel Boutros wrote:
>>> Hello Ted,
>>>
>>>
>>> What we tested shows that once credit has been made available to the 
>>> dispatch router, it remains even if no more consumers are connected to it. 
>>> So as Anouchka said any new message sent to the broker is being taken by 
>>> the dispatch router which has no consumer. So no other valid consumer on 
>>> the broker can consume it.
>>>
>>>
>>> Our questions:
>>>
>>> * Do you confirm this behavior is a bug because the dispatch router should 
>>> only consume when a valid peer is connected to it?
>>
>> This behavior is not a bug.  The router is designed to prefetch a number
>> of deliveries from the broker once there is at least one consumer.  This
>> prefetch is the link-capacity of the broker connection (defaults to
>> 250).  It might be possible for the router to revoke credit and release
>> all of its prefetched deliveries once it becomes aware that there are no
>> more consumers in the network.  This would allow the broker to deliver
>> those messages to other directly connected consumers.
>>
>> If you are designing a system in which the router network is one of
>> multiple consumers on a broker's queue, you will have to deal with the
>> prefetch issue.  It is not practical for the router network to propagate
>> real-time credit information across the routers (i.e. issue only enough
>> credit to the broker to match downrange consumer credit).
>>
>>>
>>> * What happens if the broker goes down? Does a consumer connected to the 
>>> dispatch router still 

Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

[Adel Boutros]

Thank you Robbie.


So If I understood correctly, in the next release of the components (Dispatch, 
Proton, JMS), the below is correctly supported because you tested on the Master 
branches. Right?


Regards,

Adel


From: Robbie Gemmell <robbie.gemm...@gmail.com>
Sent: Friday, February 24, 2017 5:43:05 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

I tried this (modified to use a temporary queue) and also modified the
Qpid JMS HelloWorld example to use a temporary queue, and ran both
against the router successfully multiple times, using the jms client
from master, dispatch from master, and proton from master.

The only odd thing was that Dispatch printed out two copies of notices
about the connection closing without the links being explicitly
detached, which is what the examples do and not something I would
consider unusual. I wouldnt really expect to see these notices, but if
so then only one copy.

Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:sender:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:$management'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:temp-queue-creator:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1'
due to parent connection end
Fri Feb 24 16:33:21 2017 CONTAINER (notice) Aborting link
'qpid-jms:receiver:ID:c7e7de5c-462b-4b0e-8ad5-2a005008c648:1:1:1:amqp:/_$temp.Cjf7UnrnQX4Ow9Z'
due to parent connection end

As an aside, the typical TemporaryQueue usage would be just to use the
destination object directly, i.e the below, not ask its name and
create another destination with that name. I tried both ways just to
check it wasnt related though and they both worked the same.
TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
managementConsumer = managementSession.createConsumer(temporaryQueue);


On 22 February 2017 at 11:33, Adel Boutros <adelbout...@live.com> wrote:
> Hello guys,
>
>
> My basic JMS API is almost ready. I will share it with you soon to have your 
> feedback.
>
>
> However, I tried one last thing by getting a random queue name and using it 
> as management reply queue to allow multiple configuration sessions 
> simultaneously but it didn't work.
>
>
> //This doesn't work and crashes the dispatch router
>
> TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
> replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
> //This is the only thing working
> replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
> managementConsumer = managementSession.createConsumer(replyToQueue);
>
>
> Can I have your input on the above?
>
> Regards,
> Adel
>
>
> 
> From: Rob Godfrey <rob.j.godf...@gmail.com>
> Sent: Wednesday, February 15, 2017 4:46:59 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> On 15 February 2017 at 16:07, Robbie Gemmell <robbie.gemm...@gmail.com>
> wrote:
>
>> On 15 February 2017 at 14:15, Adel Boutros <adelbout...@live.com> wrote:
>> > Hello guys,
>> >
>> >
>> > Based on the discussion, we are currently writing a Java API based on
>> JMS to configure the dispatch router. I have so far managed to do the
>> following:
>> >
>> > * Create, Read, Delete addresses
>> >
>> > * Create, Read, Delete connectors
>> >
>> >
>> > Config:
>> >
>> > Dispatch Router 0.7.0
>> >
>> > JMS 0.11.1
>> >
>> >
>> > And I have noticed some problems and differences:
>> >
>> >
>> > 1) It seems some calls return ObjectMessage and some TextMessage (This
>> is on the side of the consumer in the replyTo)
>> >
>> > For example, creating twice the same queue will fail but the second call
>> will return a JmsTextMessage with an empty body and status code 400
>> >
>>
>> The client treats messages with an amqp-value sectioning containing
>> null/nothing as a TextMessage with null value if they arent annotated

Re: [Qpid Dispatch] Message States on Web Management Console of Qpid Java Broker

[Adel Boutros]

That's perfectly clear! In our use cases, the default behavior will be enough 
for now.


Thanks,

Adel


From: Ted Ross <tr...@redhat.com>
Sent: Friday, February 24, 2017 11:52:37 AM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Message States on Web Management Console of Qpid 
Java Broker

Sorry Adel, I should have been more clear.  I meant that it might be
possible to design and code a new feature for the router to allow it to
revoke and release when the last consumer is gone from the network.

I don't think this would be the desirable default behavior however.  It
would only be useful if there were consumers on the broker that access
the broker directly and not through the router network.  If all the
consumers access the broker through the routers, the current behavior is
more efficient.

-Ted

On 02/24/2017 09:01 AM, Adel Boutros wrote:
> Thank you Ted for your clarifications. However, there is still something 
> confusing:
>
>
> You said "It might be possible for the router to revoke credit and release 
> all of its prefetched deliveries once it becomes aware that there are no more 
> consumers in the network".
>
>
> However, this is not what we are experiencing as the dispatch router is still 
> fetching newly sent messages after all consumers have been closed on the 
> dispatch router (So no consumers are connected to it) which contradicts the 
> previous hypothesis, no?
>
>
> What triggers the "it might"?
>
>
> Regards,
>
> Adel
>
> 
> From: Ted Ross <tr...@redhat.com>
> Sent: Thursday, February 23, 2017 9:48:32 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Message States on Web Management Console of Qpid 
> Java Broker
>
>
> On 02/23/2017 05:52 PM, Adel Boutros wrote:
>> Hello Ted,
>>
>>
>> What we tested shows that once credit has been made available to the 
>> dispatch router, it remains even if no more consumers are connected to it. 
>> So as Anouchka said any new message sent to the broker is being taken by the 
>> dispatch router which has no consumer. So no other valid consumer on the 
>> broker can consume it.
>>
>>
>> Our questions:
>>
>> * Do you confirm this behavior is a bug because the dispatch router should 
>> only consume when a valid peer is connected to it?
>
> This behavior is not a bug.  The router is designed to prefetch a number
> of deliveries from the broker once there is at least one consumer.  This
> prefetch is the link-capacity of the broker connection (defaults to
> 250).  It might be possible for the router to revoke credit and release
> all of its prefetched deliveries once it becomes aware that there are no
> more consumers in the network.  This would allow the broker to deliver
> those messages to other directly connected consumers.
>
> If you are designing a system in which the router network is one of
> multiple consumers on a broker's queue, you will have to deal with the
> prefetch issue.  It is not practical for the router network to propagate
> real-time credit information across the routers (i.e. issue only enough
> credit to the broker to match downrange consumer credit).
>
>>
>> * What happens if the broker goes down? Does a consumer connected to the 
>> dispatch router still receives the message as it is currently in the 
>> dispatch router's memory?
>
> If the broker goes down, any undelivered messages prefetched by the
> router shall be dropped and never delivered.  Any prefetched messages
> that have been routed to a destination shall continue to be delivered
> but will be in-doubt in the broker if they are durable.
>
>>
>>
>> Regards,
>>
>> Adel
>>
>> 
>> From: Ted Ross <tr...@redhat.com>
>> Sent: Thursday, February 23, 2017 6:09:40 PM
>> To: users@qpid.apache.org
>> Subject: Re: [Qpid Dispatch] Message States on Web Management Console of 
>> Qpid Java Broker
>>
>> Actually, the router does not send the messages back to the broker.  It
>> only sends back dispositions (modified, delivery-failed=true).  The
>> transfers that you noted as going back to the broker are actually the
>> broker resending the messages to the router (The <- arrow direction
>> denotes incoming deliveries from the router's perspective).
>>
>> -Ted
>>
>> On 02/23/2017 04:01 PM, Anouchka El Asmar wrote:
>>> Hello,
>>>
>>> As advised, I tried tracing the connection between the router and the
>>> broker. I worte this simple code that sends and receive a message:
>>>

Re: [Qpid Dispatch] Message States on Web Management Console of Qpid Java Broker

[Adel Boutros]

Thank you Ted for your clarifications. However, there is still something 
confusing:


You said "It might be possible for the router to revoke credit and release all 
of its prefetched deliveries once it becomes aware that there are no more 
consumers in the network".


However, this is not what we are experiencing as the dispatch router is still 
fetching newly sent messages after all consumers have been closed on the 
dispatch router (So no consumers are connected to it) which contradicts the 
previous hypothesis, no?


What triggers the "it might"?


Regards,

Adel


From: Ted Ross <tr...@redhat.com>
Sent: Thursday, February 23, 2017 9:48:32 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Message States on Web Management Console of Qpid 
Java Broker


On 02/23/2017 05:52 PM, Adel Boutros wrote:
> Hello Ted,
>
>
> What we tested shows that once credit has been made available to the dispatch 
> router, it remains even if no more consumers are connected to it. So as 
> Anouchka said any new message sent to the broker is being taken by the 
> dispatch router which has no consumer. So no other valid consumer on the 
> broker can consume it.
>
>
> Our questions:
>
> * Do you confirm this behavior is a bug because the dispatch router should 
> only consume when a valid peer is connected to it?

This behavior is not a bug.  The router is designed to prefetch a number
of deliveries from the broker once there is at least one consumer.  This
prefetch is the link-capacity of the broker connection (defaults to
250).  It might be possible for the router to revoke credit and release
all of its prefetched deliveries once it becomes aware that there are no
more consumers in the network.  This would allow the broker to deliver
those messages to other directly connected consumers.

If you are designing a system in which the router network is one of
multiple consumers on a broker's queue, you will have to deal with the
prefetch issue.  It is not practical for the router network to propagate
real-time credit information across the routers (i.e. issue only enough
credit to the broker to match downrange consumer credit).

>
> * What happens if the broker goes down? Does a consumer connected to the 
> dispatch router still receives the message as it is currently in the dispatch 
> router's memory?

If the broker goes down, any undelivered messages prefetched by the
router shall be dropped and never delivered.  Any prefetched messages
that have been routed to a destination shall continue to be delivered
but will be in-doubt in the broker if they are durable.

>
>
> Regards,
>
> Adel
>
> 
> From: Ted Ross <tr...@redhat.com>
> Sent: Thursday, February 23, 2017 6:09:40 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Dispatch] Message States on Web Management Console of Qpid 
> Java Broker
>
> Actually, the router does not send the messages back to the broker.  It
> only sends back dispositions (modified, delivery-failed=true).  The
> transfers that you noted as going back to the broker are actually the
> broker resending the messages to the router (The <- arrow direction
> denotes incoming deliveries from the router's perspective).
>
> -Ted
>
> On 02/23/2017 04:01 PM, Anouchka El Asmar wrote:
>> Hello,
>>
>> As advised, I tried tracing the connection between the router and the
>> broker. I worte this simple code that sends and receive a message:
>>
>> Connection connection = null;
>> try {
>> ConnectionFactory connectionFactory = new
>> JmsConnectionFactory("amqp://localhost:10501");
>> connection = connectionFactory.createConnection();
>> Session session = connection.createSession(false,
>> Session.CLIENT_ACKNOWLEDGE);
>> Queue destination = session.createQueue("queue");
>> MessageProducer producer = session.createProducer(destination);
>> connection.start();
>> TextMessage message = session.createTextMessage("Hello Adoul!");
>>
>> producer.send(message);
>> MessageConsumer consumer = session.createConsumer(destination);
>>
>> TextMessage received = (TextMessage) consumer.receive();
>>
>> consumer.close();
>>
>> } catch (JMSException e) {
>> e.printStackTrace();
>> } finally {
>> if (connection != null)
>> connection.close();
>> }
>>
>>
>> All the messages are directly acquired by the dispatch router and when
>> I close the connection, it resends them to the broker.
>>
>> Also, any new message sent direclty to the broker (not through the
>> dispatch router) will be directly acquired by the 

Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

[Adel Boutros]

Thank you Ganesh.


In that case, I will stick to using qdstat for the moment.


Regards,

Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Wednesday, February 22, 2017 5:12:23 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms



- Original Message -
> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Wednesday, February 22, 2017 10:58:42 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> Hello,
>
>
> One more issue: I am trying to replicate a "qdstat -a" to get the statistics
> of the addresses.
>
> It seems the 'name' and 'identity' fields returned are always prefixed by
> some weird combinations "L" or "M0" or "L$", etc.  Is this expected?
>

The "L" or "M" etc are used by qdstat to display some additional information in 
its output.

If you look in the qdstat python program, you will see the following -

def _addr_class(self, addr):
if not addr:
return ""
if addr[0] == 'M' : return "mobile"
if addr[0] == 'R' : return "router"
if addr[0] == 'A' : return "area"
if addr[0] == 'L' : return "local"
if addr[0] == 'T' : return "topo"
if addr[0] == 'C' : return "link-in"
if addr[0] == 'D' : return "link-out"
return "unknown: %s" % addr[0]

But, I agree that the addresses themselves should not have these prefixes.

There is a JIRA for this already -

https://issues.apache.org/jira/browse/DISPATCH-450

I am not sure we can get to this before the 0.8 release but we will try.

In the meantime, you could use the same logic that qdstat uses.

Thanks.

>
> Output
>
> --
>
> attributeNames: [name, identity, type, key, distribution, inProcess,
> subscriberCount, remoteCount, containerCount, remoteHostRouters,
> deliveriesIngress, deliveriesEgress, deliveriesTransit,
> deliveriesToContainer, deliveriesFromContainer, transitOutstanding,
> trackedDeliveries]
>
> results: [[Lqdhello, Lqdhello, org.apache.qpid.dispatch.router.address,
> Lqdhello, flood, 1, 0, 0, 0, [], 0, 0, 0, 0, 1379, null, 0], [Lqdrouter,
> Lqdrouter, org.apache.qpid.dispatch.router.address, Lqdrouter, flood, 1, 0,
> 0, 0, [], 0, 0, 0, 0, 0, null, 0], [Lqdrouter.ma, Lqdrouter.ma,
> org.apache.qpid.dispatch.router.address, Lqdrouter.ma, multicast, 1, 0, 0,
> 0, [], 0, 0, 0, 0, 0, null, 0], [Tqdrouter, Tqdrouter,
> org.apache.qpid.dispatch.router.address, Tqdrouter, flood, 1, 0, 0, 0, [],
> 0, 0, 0, 0, 46, null, 0], [Tqdrouter.ma, Tqdrouter.ma,
> org.apache.qpid.dispatch.router.address, Tqdrouter.ma, multicast, 1, 0, 0,
> 0, [], 0, 0, 0, 0, 2, null, 0], [M0$management, M0$management,
> org.apache.qpid.dispatch.router.address, M0$management, closest, 1, 0, 0, 0,
> [], 7, 0, 0, 7, 0, null, 0], [L$management, L$management,
> org.apache.qpid.dispatch.router.address, L$management, closest, 1, 0, 0, 0,
> [], 0, 0, 0, 0, 0, null, 0], [L$_management_internal,
> L$_management_internal, org.apache.qpid.dispatch.router.address,
> L$_management_internal, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0],
> [L$displayname, L$displayname, org.apache.qpid.dispatch.router.address,
> L$displayname, closest, 1, 0, 0, 0, [], 0, 0, 0, 0, 0, null, 0],
> [M0$management_reply_queue, M0$management_reply_queue,
> org.apache.qpid.dispatch.router.address, M0$management_reply_queue,
> balanced, 0, 1, 0, 0, [], 0, 0, 0, 0, 0, null, 0]]
>
>
>
> Code
>
> ---
>
> ConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://green-lx-slave1:10501");
> Connection managementConnection = connectionFactory.createConnection();
> Session managementSession = managementConnection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> Queue managementQueue = managementSession.createQueue("$management");
> MessageProducer managementProducer =
> managementSession.createProducer(managementQueue);
> Queue replyToQueue =
> managementSession.createQueue("$management_reply_queue");
> MessageConsumer managementConsumer =
> managementSession.createConsumer(replyToQueue);
> managementConnection.start();
>
> // An object message should be used because the Map and List content must be
> encoded with AMQP encoding.
> ObjectMessage objectMessage = managementSession.createObjectMessage();
>
> // Setting management message header properties
> // JMS_AMQP_TYPED_ENCODING is a temporary solution that is used by qpid-jms
> to encode the message content with AMQP encoding before sending it.
> objectMessage.setBooleanProperty("JMS_AMQP

Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

[Adel Boutros]

Hello,


One more issue: I am trying to replicate a "qdstat -a" to get the statistics of 
the addresses.

It seems the 'name' and 'identity' fields returned are always prefixed by  some 
weird combinations "L" or "M0" or "L$", etc.  Is this expected?


Output

--

attributeNames: [name, identity, type, key, distribution, inProcess, 
subscriberCount, remoteCount, containerCount, remoteHostRouters, 
deliveriesIngress, deliveriesEgress, deliveriesTransit, deliveriesToContainer, 
deliveriesFromContainer, transitOutstanding, trackedDeliveries]

results: [[Lqdhello, Lqdhello, org.apache.qpid.dispatch.router.address, 
Lqdhello, flood, 1, 0, 0, 0, [], 0, 0, 0, 0, 1379, null, 0], [Lqdrouter, 
Lqdrouter, org.apache.qpid.dispatch.router.address, Lqdrouter, flood, 1, 0, 0, 
0, [], 0, 0, 0, 0, 0, null, 0], [Lqdrouter.ma, Lqdrouter.ma, 
org.apache.qpid.dispatch.router.address, Lqdrouter.ma, multicast, 1, 0, 0, 0, 
[], 0, 0, 0, 0, 0, null, 0], [Tqdrouter, Tqdrouter, 
org.apache.qpid.dispatch.router.address, Tqdrouter, flood, 1, 0, 0, 0, [], 0, 
0, 0, 0, 46, null, 0], [Tqdrouter.ma, Tqdrouter.ma, 
org.apache.qpid.dispatch.router.address, Tqdrouter.ma, multicast, 1, 0, 0, 0, 
[], 0, 0, 0, 0, 2, null, 0], [M0$management, M0$management, 
org.apache.qpid.dispatch.router.address, M0$management, closest, 1, 0, 0, 0, 
[], 7, 0, 0, 7, 0, null, 0], [L$management, L$management, 
org.apache.qpid.dispatch.router.address, L$management, closest, 1, 0, 0, 0, [], 
0, 0, 0, 0, 0, null, 0], [L$_management_internal, L$_management_internal, 
org.apache.qpid.dispatch.router.address, L$_management_internal, closest, 1, 0, 
0, 0, [], 0, 0, 0, 0, 0, null, 0], [L$displayname, L$displayname, 
org.apache.qpid.dispatch.router.address, L$displayname, closest, 1, 0, 0, 0, 
[], 0, 0, 0, 0, 0, null, 0], [M0$management_reply_queue, 
M0$management_reply_queue, org.apache.qpid.dispatch.router.address, 
M0$management_reply_queue, balanced, 0, 1, 0, 0, [], 0, 0, 0, 0, 0, null, 0]]



Code

---

ConnectionFactory connectionFactory = new 
JmsConnectionFactory("amqp://green-lx-slave1:10501");
Connection managementConnection = connectionFactory.createConnection();
Session managementSession = managementConnection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
Queue managementQueue = managementSession.createQueue("$management");
MessageProducer managementProducer = 
managementSession.createProducer(managementQueue);
Queue replyToQueue = managementSession.createQueue("$management_reply_queue");
MessageConsumer managementConsumer = 
managementSession.createConsumer(replyToQueue);
managementConnection.start();

// An object message should be used because the Map and List content must be 
encoded with AMQP encoding.
ObjectMessage objectMessage = managementSession.createObjectMessage();

// Setting management message header properties
// JMS_AMQP_TYPED_ENCODING is a temporary solution that is used by qpid-jms to 
encode the message content with AMQP encoding before sending it.
objectMessage.setBooleanProperty("JMS_AMQP_TYPED_ENCODING", true);
objectMessage.setStringProperty("operation", "QUERY");
objectMessage.setStringProperty("type", 
"org.apache.qpid.dispatch.router.address");
objectMessage.setStringProperty("name", "self");
objectMessage.setJMSReplyTo(replyToQueue);

managementProducer.send(objectMessage);

ObjectMessage replyMessage = (ObjectMessage) managementConsumer.receive();

Map<String, Object> resultObject = (Map<String, Object>) 
replyMessage.getObject();
for (Map.Entry<String, Object> entry : resultObject.entrySet()) {
    System.out.println(entry.getKey() + ": " + entry.getValue());
}

managementConnection.close();

Regards,

Adel

From: Adel Boutros <adelbout...@live.com>
Sent: Wednesday, February 22, 2017 12:33:32 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

Hello guys,


My basic JMS API is almost ready. I will share it with you soon to have your 
feedback.


However, I tried one last thing by getting a random queue name and using it as 
management reply queue to allow multiple configuration sessions simultaneously 
but it didn't work.


//This doesn't work and crashes the dispatch router

TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
managementConsumer = managementSession.createConsumer(replyToQueue);

//This is the only thing working
replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
managementConsumer = managementSession.createConsumer(replyToQueue);


Can I have your input on the above?

Regards,
Adel



From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Wednesday, February 15, 2017 4:46:59 PM
To: 

Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

[Adel Boutros]

Hello guys,


My basic JMS API is almost ready. I will share it with you soon to have your 
feedback.


However, I tried one last thing by getting a random queue name and using it as 
management reply queue to allow multiple configuration sessions simultaneously 
but it didn't work.


//This doesn't work and crashes the dispatch router

TemporaryQueue temporaryQueue = managementSession.createTemporaryQueue();
replyToQueue = managementSession.createQueue(temporaryQueue.getQueueName());
managementConsumer = managementSession.createConsumer(replyToQueue);

//This is the only thing working
replyToQueue = managementSession.createQueue("HARD_CODED_REPLY_QUEUE");
managementConsumer = managementSession.createConsumer(replyToQueue);


Can I have your input on the above?

Regards,
Adel



From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Wednesday, February 15, 2017 4:46:59 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

On 15 February 2017 at 16:07, Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:

> On 15 February 2017 at 14:15, Adel Boutros <adelbout...@live.com> wrote:
> > Hello guys,
> >
> >
> > Based on the discussion, we are currently writing a Java API based on
> JMS to configure the dispatch router. I have so far managed to do the
> following:
> >
> > * Create, Read, Delete addresses
> >
> > * Create, Read, Delete connectors
> >
> >
> > Config:
> >
> > Dispatch Router 0.7.0
> >
> > JMS 0.11.1
> >
> >
> > And I have noticed some problems and differences:
> >
> >
> > 1) It seems some calls return ObjectMessage and some TextMessage (This
> is on the side of the consumer in the replyTo)
> >
> > For example, creating twice the same queue will fail but the second call
> will return a JmsTextMessage with an empty body and status code 400
> >
>
> The client treats messages with an amqp-value sectioning containing
> null/nothing as a TextMessage with null value if they arent annotated
> to say otherwise, I'd guess thats where that comes from.
>
> >
> > 2) Returned statusCode differs between Connector and Address
> >
> > Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> >
> >
> > * Connector operations return java.lang.Long
> > * Address operations return org.apache.qpid.proton.amqp.UnsignedInteger
> >
>
> The router is presumably sending different values back for the
> different operations here, a long and a uint. The router should
> perhaps be consistent, and the client should perhaps not be returning
> the uint object either way.
>
> The last draft of the management spec seems to say the status code
> should be 'integer', im not clear if it means int (not uint)
> specifically, or just any integral type value.
>
>
The specification should definitely say which type should - so we'll fix
that in the next draft.  I'd suggest we should int (in AMQP terms) leading
to a java.lang.Integer type in the property you see through Java.

-- Rob



> >
> > 3) Create connector twice makes dispatch router crash.  I don't have the
> issue when creating addresses.
> > On the second create call,  JMS client receives a normal reply
> containing a statusCode of an exception. After I close the connection to
> the dispatch router via JMS (connection.close), I have the below crash
> >
> > (gdb) where
> > #0  0x7f27194448a5 in raise () from /lib64/libc.so.6
> > #1  0x7f2719446085 in abort () from /lib64/libc.so.6
> > #2  0x7f27194827b7 in __libc_message () from /lib64/libc.so.6
> > #3  0x7f27194880e6 in malloc_printerr () from /lib64/libc.so.6
> > #4  0x7f271a40f109 in qd_hash_remove_by_handle (h=Unhandled dwarf
> expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/hash.c:320
> > #5  0x7f271a42247d in qdr_route_check_id_for_deletion_CT
> (cid=0x7f2708055850, core=Unhandled dwarf expression opcode 0xfa
> > ) at /qpid-dispatch-0.7.0/src/router_core/route_control.c:57
> > #6  0x7f271a41e8d3 in qdr_connection_closed_CT (core=0x13d2d30,
> action=Unhandled dwarf expression opcode 0xf3
> > ) at /qpid-dispatch-0.7.0/src/router_core/connections.c:961
> > #7  0x7f271a423f30 in router_core_thread (arg=0x13d2d30) at
> /qpid-dispatch-0.7.0/src/router_core/router_core_thread.c:83
> > #8  0x7f2719f8c851 in start_thread () from /lib64/libpthread.so.0
> > #9  0x7f27194fa90d in clone () from /lib64/libc.so.6
> >
> >
> > Wed Feb 15 12:20:52 2017 AGENT (error) Error performing CREATE:
> org.apache.qpid.dispatch.connector: Duplicate value 'connector/
> 127.0.0.1:5915:d

Re: [Dispatch Router] Unexpected behavior when starting the same dispatch router twice

[Adel Boutros]

Thanks Alan,


Do not hesitate if you have any comment or feedback.


Regards,

Adel


From: Alan Conway <acon...@redhat.com>
Sent: Wednesday, February 15, 2017 4:41:06 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] Unexpected behavior when starting the same 
dispatch router twice

On Tue, 2017-02-14 at 20:35 +, Adel Boutros wrote:
> Hello,
>
>
> Was anyone able to take a look at the submitted patches?

I am just about to. Have been working on the proton side and on other
stuff lately but am going back to dispatch now. I will try to ensure
that your fixes either get committed or that I don't step on them if
they are in areas that I am changing. Will give you a preview on github
ASAP.

Cheers,
Alan.

>
>
> Regards,
>
> Adel
>
> ________
> From: Adel Boutros <adelbout...@live.com>
> Sent: Thursday, February 2, 2017 4:24:30 PM
> To: users@qpid.apache.org
> Subject: Re: [Dispatch Router] Unexpected behavior when starting the
> same dispatch router twice
>
> Hello Alan,
>
>
> Just to not lose the history, I will reply to your before last mail
> here.
>
>
> My changes does impact the 3 files you mentioned however they are
> very trivial...
>
>
> Regarding libuv, I tried to compile it on Linux (Red Hat 6.4) but one
> of the tests failed and Google suggested many encountered that
> problem (which I forgot because I did it some time ago :( ). So I
> didn't even try it on Solaris.
>
>
> As Solaris is one of our main platforms, I am more than happy to test
> whatever developments you have on Solaris but the only problem I
> might have is the bandwidth I will have to fix any errors which will
> be detected.
>
>
> Regards,
>
> Adel
>
>
> 
> From: Alan Conway <acon...@redhat.com>
> Sent: Thursday, February 2, 2017 4:23:23 PM
> To: users@qpid.apache.org
> Subject: Re: [Dispatch Router] Unexpected behavior when starting the
> same dispatch router twice
>
> On Thu, 2017-02-02 at 15:16 +, Adel Boutros wrote:
> > d have a look at them.
> >
> > https://issues.apache.org/jira/browse/DISPATCH-627
> > https://issues.apache.org/jira/browse/DISPATCH-626
> > https://issues.apache.org/jira/browse/DISPATCH-624
> > https://issues.apache.org/jira/browse/DISPATCH-623
> > https://issues.apache.org/jira/browse/DISPATCH-622
> > https://issues.apache.org/jira/browse/DISPATCH-621
> > https://issues.apache.org/jira/browse/DISPATCH-620
> > https://issues.apache.org/jira/browse/DISPATCH-619
> > https://issues.apache.org/jira/browse/DISPATCH-618
> > https://issues.apache.org/jira/browse/DISPATCH-617
> > https://issues.apache.org/jira/browse/DISPATCH-616
> > https://issues.apache.org/jira/browse/DISPATCH-615
> > https://issues.apache.org/jira/browse/DISPATCH-614
> > https://issues.apache.org/jira/browse/DISPATCH-613
> > https://issues.apache.org/jira/browse/DISPATCH-612
>
>
> I've added a comment to the JIRA and I will review them all before I
> commit the proactor work. I may ask you to test a preview of the work
> on solaris before I commit depending on how complicated it looks.
>
> Cheers,
> Alan.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms

[Adel Boutros]

tch doesn't like what
> >>> the client is doing for createTemporaryQueue, but doesn't fail in a
> >>> very nice way, and the client then doesnt notice that things have gone
> >>> south in a somewhat unexpected way.
> >>>
> >>> The client opens a sending link with 'dynamic' target in order to
> >>> create a dynamic node for use as a TemporaryQueue address/destination
> >>> object, which specific consumers/producers are then created against by
> >>> the application. Dispatch doesn't seem to like that but erroneously
> >>> attaches the link 'successfully', though doesnt set a target address
> >>> as is expected. The client then doesnt notice this happened (its
> >>> checking for the link being refused, which it wasn't), allowing the
> >>> application to proceed as far as creating consumers/procuers using the
> >>> TemporaryQueue object, with creation of the e.g Consumer then failing
> >>> since the attach doesnt contain the needed information and leads to
> >>> Dispatch detaching it with the error (though it again doesnt actually
> >>> indicate its refusing the link during the attach response, as it
> >>> probably should have in this case).
> >>>
> >>> Making the client detect the current failure and having it throw an
> >>> aexception from createTemporaryQueue is simple enough.
> >>>
> >>> Hacking the client to use a dynamic recieving link instead, an address
> >>> was returned by Dispatch in the attach response as expected, however a
> >>> consumer on the resulting TemporaryQueue object using this address
> >>> still didnt get the message I sent to the same place. If I also gave
> >>> some credit on the link backing the TemporaryQeueue object itself then
> >>> that link gets sent the message by Dispatch, though this of no use for
> >>> the JMS client.
> >>>
> >>> Needs some more investigation, and I'll need to discuss with some
> >>> folks more familiar with Dispatch.
> >>>
> >>> Robbie
> >>>
> >>> On 26 January 2017 at 13:39, Adel Boutros <adelbout...@live.com>
> wrote:
> >>>
> >>>> Hello Robbie,
> >>>>
> >>>>
> >>>> I replaced the "createQueue" with "createTemporaryQueue" for the reply
> >>>> consumer and activated PN_TRACE_FRM on Dispatch Router and JMS Client.
> >>>>
> >>>>
> >>>> PS: As Rabih stated before, we are using the same connection and same
> >>>> session to create the  JMSProducer for the request and the
> JMSConsumer for
> >>>> the reply.
> >>>>
> >>>>
> >>>> Exception
> >>>> ---
> >>>> javax.jms.IllegalStateException: The MessageConsumer was closed due
> to
> >>>> an unrecoverable error.
> >>>> at org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessag
> >>>> eConsumer.java:330)
> >>>> at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageCon
> >>>> sumer.java:196)
> >>>> at murex.messaging.client.JmsTest.main(JmsTest.java:57)
> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >>>> ssorImpl.java:62)
> >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >>>> thodAccessorImpl.java:43)
> >>>> at java.lang.reflect.Method.invoke(Method.java:498)
> >>>> at com.intellij.rt.execution.application.AppMain.main(
> AppMain.java:147)
> >>>> Caused by: javax.jms.JMSException: No route to the destination node
> >>>> [condition = qd:no-route-to-dest]
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >>>> tion(AmqpSupport.java:150)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToExcep
> >>>> tion(AmqpSupport.java:105)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.remot
> >>>> elyClosed(AmqpAbstractResource.java:147)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.proce
> >>>> ssRemoteClose(AmqpAbstractResource.java:251)
> >>>> at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdate
> >>>> s(AmqpProvider.java:795)
> >>>> at or

Re: [Dispatch Router] Unexpected behavior when starting the same dispatch router twice

[Adel Boutros]

Hello,


Was anyone able to take a look at the submitted patches?


Regards,

Adel


From: Adel Boutros <adelbout...@live.com>
Sent: Thursday, February 2, 2017 4:24:30 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] Unexpected behavior when starting the same 
dispatch router twice

Hello Alan,


Just to not lose the history, I will reply to your before last mail here.


My changes does impact the 3 files you mentioned however they are very 
trivial...


Regarding libuv, I tried to compile it on Linux (Red Hat 6.4) but one of the 
tests failed and Google suggested many encountered that problem (which I forgot 
because I did it some time ago :( ). So I didn't even try it on Solaris.


As Solaris is one of our main platforms, I am more than happy to test whatever 
developments you have on Solaris but the only problem I might have is the 
bandwidth I will have to fix any errors which will be detected.


Regards,

Adel



From: Alan Conway <acon...@redhat.com>
Sent: Thursday, February 2, 2017 4:23:23 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] Unexpected behavior when starting the same 
dispatch router twice

On Thu, 2017-02-02 at 15:16 +, Adel Boutros wrote:
> d have a look at them.
>
> https://issues.apache.org/jira/browse/DISPATCH-627
> https://issues.apache.org/jira/browse/DISPATCH-626
> https://issues.apache.org/jira/browse/DISPATCH-624
> https://issues.apache.org/jira/browse/DISPATCH-623
> https://issues.apache.org/jira/browse/DISPATCH-622
> https://issues.apache.org/jira/browse/DISPATCH-621
> https://issues.apache.org/jira/browse/DISPATCH-620
> https://issues.apache.org/jira/browse/DISPATCH-619
> https://issues.apache.org/jira/browse/DISPATCH-618
> https://issues.apache.org/jira/browse/DISPATCH-617
> https://issues.apache.org/jira/browse/DISPATCH-616
> https://issues.apache.org/jira/browse/DISPATCH-615
> https://issues.apache.org/jira/browse/DISPATCH-614
> https://issues.apache.org/jira/browse/DISPATCH-613
> https://issues.apache.org/jira/browse/DISPATCH-612


I've added a comment to the JIRA and I will review them all before I
commit the proactor work. I may ask you to test a preview of the work
on solaris before I commit depending on how complicated it looks.

Cheers,
Alan.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Qpid Proton 0.17.0

[Adel Boutros]

Symbolic +1


Compiled Proton + unit tests on Linux (GCC 4.9.1)

Compiled Proton + unit tests on Windows (Visual Studio 2013)

Compiled Proton + unit tests on Solaris x86 (SunStudio 12.1)

Compiled Proton + unit tests on Solaris Sparc (SunStudio 12.1)

Compiled Qpid Dispatch 0.7.0 + unit tests (With my patches)  on Linux, Solaris 
x86 and Solaris Sparc

Full test suite green on our side


PS: We only compile Proton-c, the C++ bindings and the Python bindings


Regards,

Adel



From: Ganesh Murthy 
Sent: Friday, February 3, 2017 7:27:34 PM
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Qpid Proton 0.17.0

+1

* Verified signatures
* Ran Qpid Dispatch unit tests successfully

I got down the bits from 
https://dist.apache.org/repos/dist/dev/qpid/proton/0.17.0-rc1/ and proceeded to 
build without disabling any binding.

I saw this error in cmake -

CMake Error at proton-c/bindings/javascript/CMakeLists.txt:177 (add_library):
   Cannot find source file:

 /home/gmurthy/opensource/qpid-proton-0.17.0/proton-c/src/object/object.c

   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
   .hxx .in .txx



 CMake Error: CMake can not determine linker language for target: 
qpid-proton-bitcode

 CMake Error: Cannot determine link language for target "qpid-proton-bitcode".

This comes from the Javascript binding being ON and goes away if turned off. 
The same problem also exists with proton 0.16

Earlier, if the javascript binding was ON and if emscripten program was not 
found, it would simply skip building the js binding but now it throws the above 
error.

Any newbie who builds proton will hit this problem will be confused.

Thoughts?

(In any case, I am giving a +1 because the above stated problem does not affect 
the way we use proton in dispatch)

Thanks.

- Original Message -
> From: "Robbie Gemmell" 
> To: users@qpid.apache.org
> Sent: Friday, February 3, 2017 12:35:47 PM
> Subject: [VOTE] Release Qpid Proton 0.17.0
>
> Hi folks,
>
> I have put together a first spin for a 0.17.0 Qpid Proton release,
> please test it and vote accordingly.
>
> Note that Proton-J is now independently released, its vote is also under way.
>
> The source archive can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.17.0-rc1/
>
> The JIRAs currently assigned are [still in need of major cleanup]:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12338663
>
> It is tagged as 0.17.0-rc1.
>
> Regards,
> Robbie
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Qpid Proton] How mandatory is Cyrus for SASL

[Adel Boutros]

In our case, we only use EXTERNAL or ANONYMOUS so it should be enough.


Is there a reason it is called "null"?


Regards,

Adel


From: Alan Conway <acon...@redhat.com>
Sent: Thursday, February 2, 2017 8:51:21 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Proton] How mandatory is Cyrus for SASL

On Thu, 2017-02-02 at 19:41 +0000, Adel Boutros wrote:
> Hello,
>
>
> I was wondering if SASL would be completely disabled in Proton if
> Cyrus was not found during compilation or is there an alternative
> implementation?
>
>
> Regards,
>
> Adel

Proton has a built-in "null" SASL impl that supports EXTERNAL, PLAIN or
ANONYMOUS. It is intended to be enough for trusted environments or if
you always use SSL/TLS to secure things.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

[Qpid Proton] How mandatory is Cyrus for SASL

[Adel Boutros]

Hello,


I was wondering if SASL would be completely disabled in Proton if Cyrus was not 
found during compilation or is there an alternative implementation?


Regards,

Adel

Re: [Dispatch Router] Unexpected behavior when starting the same dispatch router twice

[Adel Boutros]

Hello Alan,


Just to not lose the history, I will reply to your before last mail here.


My changes does impact the 3 files you mentioned however they are very 
trivial...


Regarding libuv, I tried to compile it on Linux (Red Hat 6.4) but one of the 
tests failed and Google suggested many encountered that problem (which I forgot 
because I did it some time ago :( ). So I didn't even try it on Solaris.


As Solaris is one of our main platforms, I am more than happy to test whatever 
developments you have on Solaris but the only problem I might have is the 
bandwidth I will have to fix any errors which will be detected.


Regards,

Adel



From: Alan Conway <acon...@redhat.com>
Sent: Thursday, February 2, 2017 4:23:23 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] Unexpected behavior when starting the same 
dispatch router twice

On Thu, 2017-02-02 at 15:16 +, Adel Boutros wrote:
> d have a look at them.
>
> https://issues.apache.org/jira/browse/DISPATCH-627
> https://issues.apache.org/jira/browse/DISPATCH-626
> https://issues.apache.org/jira/browse/DISPATCH-624
> https://issues.apache.org/jira/browse/DISPATCH-623
> https://issues.apache.org/jira/browse/DISPATCH-622
> https://issues.apache.org/jira/browse/DISPATCH-621
> https://issues.apache.org/jira/browse/DISPATCH-620
> https://issues.apache.org/jira/browse/DISPATCH-619
> https://issues.apache.org/jira/browse/DISPATCH-618
> https://issues.apache.org/jira/browse/DISPATCH-617
> https://issues.apache.org/jira/browse/DISPATCH-616
> https://issues.apache.org/jira/browse/DISPATCH-615
> https://issues.apache.org/jira/browse/DISPATCH-614
> https://issues.apache.org/jira/browse/DISPATCH-613
> https://issues.apache.org/jira/browse/DISPATCH-612


I've added a comment to the JIRA and I will review them all before I
commit the proactor work. I may ask you to test a preview of the work
on solaris before I commit depending on how complicated it looks.

Cheers,
Alan.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Dispatch Router] Unexpected behavior when starting the same dispatch router twice

[Adel Boutros]

Hello Alan,


Great to hear that!


I don't know what are the classes in the Dispatch Router which will be 
refactored and maybe some of my patches will be irrelevant.

It took me 2 weeks to be able to compile and test the Dispatch Router 0.7.0 (A 
large part of the code evolved since 0.5.0).


All the patches are listed below. I hope you could have a look at them.

https://issues.apache.org/jira/browse/DISPATCH-627
https://issues.apache.org/jira/browse/DISPATCH-626
https://issues.apache.org/jira/browse/DISPATCH-624
https://issues.apache.org/jira/browse/DISPATCH-623
https://issues.apache.org/jira/browse/DISPATCH-622
https://issues.apache.org/jira/browse/DISPATCH-621
https://issues.apache.org/jira/browse/DISPATCH-620
https://issues.apache.org/jira/browse/DISPATCH-619
https://issues.apache.org/jira/browse/DISPATCH-618
https://issues.apache.org/jira/browse/DISPATCH-617
https://issues.apache.org/jira/browse/DISPATCH-616
https://issues.apache.org/jira/browse/DISPATCH-615
https://issues.apache.org/jira/browse/DISPATCH-614
https://issues.apache.org/jira/browse/DISPATCH-613
https://issues.apache.org/jira/browse/DISPATCH-612

Regards,

Adel



From: Alan Conway <acon...@redhat.com>
Sent: Thursday, February 2, 2017 4:03:50 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] Unexpected behavior when starting the same 
dispatch router twice

On Fri, 2017-01-20 at 15:10 +, Adel Boutros wrote:
> We have not yet compiled proton with libuv so I might not be that
> straightforward for us.
>
>
> I hope the new I/O will work easily because I have already around 7
> patches for 0.7.0 and I am at 27% compilation.
>
>

So do I :) If you want a preview I can put snapshots on a branch. It is
 sort-of working but still full of holes where I cut out the old
driver, and it falls down one of them from time to time. I am filling
them in as fast as I can...

I'll take account of any patches on master as I go, if you have patches
that aren't ported to master for some reason, and you think they might
be relevant let me know.

Lets track it here: https://issues.apache.org/jira/browse/DISPATCH-390


> Regards,
>
> Adel
>
> 
> From: Ted Ross <tr...@redhat.com>
> Sent: Friday, January 20, 2017 3:58:51 PM
> To: users@qpid.apache.org
> Subject: Re: [Dispatch Router] Unexpected behavior when starting the
> same dispatch router twice
>
> You should be aware that Alan Conway is working on converting the
> Dispatch I/O layer to use Proton proactor and libuv.  This might make
> the port to Solaris (and Windows) much easier.
>
> -Ted
>
>
> On 01/20/2017 09:54 AM, Adel Boutros wrote:
> > I hope by that time I will have finished porting Dispatch Router to
> > Solaris and submitted my patches. There have been a lot of changes
> > since the last time we tried to compile 0.5 on Solaris :(
> >
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Ted Ross <tr...@redhat.com>
> > Sent: Friday, January 20, 2017 2:50:49 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Dispatch Router] Unexpected behavior when starting
> > the same dispatch router twice
> >
> > Actually, we haven't settled on a schedule for 0.8.0 yet.  There
> > are 90
> > issues assigned to 0.8.0 with 11 currently not resolved.
> >
> > I think mid-to-late February would be a good timeframe for this
> > release.
> >
> > -Ted
> >
> > On 01/20/2017 08:39 AM, Ganesh Murthy wrote:
> > > 0.8 is expected to come out around mid February.
> > >
> > > - Original Message -
> > > > From: "Adel Boutros" <adelbout...@live.com>
> > > > To: users@qpid.apache.org
> > > > Sent: Friday, January 20, 2017 8:31:40 AM
> > > > Subject: Re: [Dispatch Router] Unexpected behavior when
> > > > starting the same dispatch router twice
> > > >
> > > > Thanks Ted!
> > > >
> > > >
> > > > Is 0.8 expected to come out soon?
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Adel
> > > >
> > > > 
> > > > From: Ted Ross <tr...@redhat.com>
> > > > Sent: Friday, January 20, 2017 2:06:24 PM
> > > > To: users@qpid.apache.org
> > > > Subject: Re: [Dispatch Router] Unexpected behavior when
> > > > starting the same
> > > > dispatch router twice
> > > >
> > > > Adel,
> > > >
> > > > This was raised as a Jira
> > > > (https://issues.apache.org/jira/brows

Re: [GitHub] qpid-dispatch pull request #140: DISPATCH-216 - Added code to skip system_te...

[Adel Boutros]

Your fix is working [??]


19: Test timeout computed to be: 1500
19: test_simple_pre_settled (system_tests_protocol_family.ProtocolFamilyTest) 
... skipped 'Skipping test..IPV6 not enabled'
19:
19: --
19: Ran 1 test in 0.001s
19:
19: OK (skipped=1)
1/1 Test #19: system_tests_protocol_family .   Passed0.11 sec

Regards,
Adel


From: Ganesh Murthy <gmur...@redhat.com>
Sent: Wednesday, February 1, 2017 4:11:14 PM
To: users@qpid.apache.org
Subject: Re: [GitHub] qpid-dispatch pull request #140: DISPATCH-216 - Added 
code to skip system_te...

Hi Adel,
Like you mentioned, the earlier PR was checking incorrect error message because 
the error message on Solaris is different.

Based on your input, I have submitted a new pull request - 
https://github.com/apache/qpid-dispatch/pull/141

Please go ahead and give that a try (after backing out the previous code). 
Please try running only the system_tests_protocol_family after applying the new 
PR. If that goes well, I will fix the other tests as well.

Thanks.

- Original Message -

> From: "Adel Boutros" <adelbout...@live.com>
> To: users@qpid.apache.org
> Sent: Wednesday, February 1, 2017 9:17:55 AM
> Subject: Re: [GitHub] qpid-dispatch pull request #140: DISPATCH-216 - Added
> code to skip system_te...

> Hello Ganesh,

> I tested your pull request and it doesn't seem that the error message you
> check for in " is_ipv6_enabled" is correct.

> In my case, Exception e is ( print ">%s: %s" %(type(e), str(e)) ): "
> : getsockaddrarg: bad family "

> I have attached the log of all the tests. This way you can see what is
> happening. I think there are multiple errors being shown.

> I am also attaching the patch which I had used to disable IPv6 brutally (Of
> course it is not a patch to be accepted but just to show you what we had to
> do to ignore the errors).

> Regards,

> Adel

> From: Ganesh Murthy <gmur...@redhat.com>
> Sent: Tuesday, January 31, 2017 8:24:12 PM
> To: users@qpid.apache.org
> Subject: Fwd: [GitHub] qpid-dispatch pull request #140: DISPATCH-216 - Added
> code to skip system_te...
> Hi Adel,
> Can you please apply this pull request in your environment and let me know if
> the system_tests_protocol_family.py tests are skipped.
> Thanks.

> - Forwarded Message -
> From: "ganeshmurthy" <g...@git.apache.org>
> To: d...@qpid.apache.org
> Sent: Tuesday, January 31, 2017 2:19:38 PM
> Subject: [GitHub] qpid-dispatch pull request #140: DISPATCH-216 - Added code
> to skip system_te...

> GitHub user ganeshmurthy opened a pull request:

> https://github.com/apache/qpid-dispatch/pull/140

> DISPATCH-216 - Added code to skip system_tests_protocol_family.py if …

> …IPv6 is turned off

> You can merge this pull request into a Git repository by running:

> $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-216

> Alternatively you can review and apply these changes as the patch at:

> https://github.com/apache/qpid-dispatch/pull/140.patch

> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:

> This closes #140

> 
> commit a0b16449e7fd257b2abee347ae211ab6a33bc53c
> Author: Ganesh Murthy <gmur...@redhat.com>
> Date: 2017-01-31T19:18:10Z

> DISPATCH-216 - Added code to skip system_tests_protocol_family.py if IPv6 is
> turned off

> 

> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---

> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org

> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org

> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org

Re: [GitHub] qpid-dispatch pull request #140: DISPATCH-216 - Added code to skip system_te...

[Adel Boutros]

Hello Ganesh,


I tested your pull request and it doesn't seem that the error message you check 
for in "is_ipv6_enabled" is correct.

In my case, Exception e is (print ">%s: %s" %(type(e), str(e))): ": getsockaddrarg: bad family"


I have attached the log of all the tests. This way you can see what is 
happening. I think there are multiple errors being shown.


I am also attaching the patch which I had used to disable IPv6 brutally (Of 
course it is not a patch to be accepted but just to show you what we had to do 
to ignore the errors).


Regards,

Adel


From: Ganesh Murthy 
Sent: Tuesday, January 31, 2017 8:24:12 PM
To: users@qpid.apache.org
Subject: Fwd: [GitHub] qpid-dispatch pull request #140: DISPATCH-216 - Added 
code to skip system_te...

Hi Adel,
   Can you please apply this pull request in your environment and let me know 
if the system_tests_protocol_family.py tests are skipped.
Thanks.

- Forwarded Message -
From: "ganeshmurthy" 
To: d...@qpid.apache.org
Sent: Tuesday, January 31, 2017 2:19:38 PM
Subject: [GitHub] qpid-dispatch pull request #140: DISPATCH-216 - Added code to 
skip system_te...

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/140

DISPATCH-216 - Added code to skip system_tests_protocol_family.py if …

…IPv6 is turned off

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-216

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/140.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #140


commit a0b16449e7fd257b2abee347ae211ab6a33bc53c
Author: Ganesh Murthy 
Date:   2017-01-31T19:18:10Z

DISPATCH-216 - Added code to skip system_tests_protocol_family.py if IPv6 
is turned off




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

test 12
  Start 12: router_policy_test

12: Test command: /python278/bin/python "/build-dir/qpid-dispatch/tests/run.py" 
"-m" "unittest" "-v" "router_policy_test"
12: Test timeout computed to be: 1500
12: Run python module 'unittest': PolicyError: u'Policy \'photoserver\' is 
invalid: Policy vhost \'photoserver\' user group \'superuser\' option 
\'remoteHosts\' connectionOption \'::1\' failed to translate: \'\'HostStruct: 
\\\'::1\\\' failed to resolve: \\\'"HostStruct: \\\'::1\\\' did not resolve to 
one of the supported address family"\\\'\'\'.'
12: Traceback (most recent call last):
12:   File "/build-dir/qpid-dispatch/tests/run.py", line 148, in 
12: runpy.run_module(sys.argv[0], alter_sys=True, run_name="__main__")
12:   File "/python278/lib/python2.7/runpy.py", line 176, in run_module
12: fname, loader, pkg_name)
12:   File "/python278/lib/python2.7/runpy.py", line 82, in _run_module_code
12: mod_name, mod_fname, mod_loader, pkg_name)
12:   File "/python278/lib/python2.7/runpy.py", line 72, in _run_code
12: exec code in run_globals
12:   File "/python278/lib/python2.7/unittest/__main__.py", line 12, in 
12: main(module=None)
12:   File "/python278/lib/python2.7/unittest/main.py", line 94, in __init__
12: self.parseArgs(argv)
12:   File "/python278/lib/python2.7/unittest/main.py", line 149, in parseArgs
12: self.createTests()
12:   File "/python278/lib/python2.7/unittest/main.py", line 158, in createTests
12: self.module)
12:   File "/python278/lib/python2.7/unittest/loader.py", line 130, in 
loadTestsFromNames
12: suites = [self.loadTestsFromName(name, module) for name in names]
12:   File "/python278/lib/python2.7/unittest/loader.py", line 91, in 
loadTestsFromName
12: module = __import__('.'.join(parts_copy))
12:   File "/qpid-dispatch-0.7.0/tests/router_policy_test.py", line 140, in 

12: class PolicyFile(TestCase):
12:   File "/qpid-dispatch-0.7.0/tests/router_policy_test.py", line 144, in 
PolicyFile
12: policy.test_load_config()
12:   File 
"/qpid-dispatch-0.7.0/python/qpid_dispatch_internal/policy/policy_local.py", 
line 712, in test_load_config
12: self.create_ruleset(ruleset[1])
12:   File 

Re: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the Dispatch Router on Linux

[Adel Boutros]

Hello Ganesh,


Actually one of our tests will require the below dispatch router to talk to 
another dispatche router So the interior mode is intended.


Regards,

Adel


From: Adel Boutros <adelbout...@live.com>
Sent: Wednesday, February 1, 2017 1:09:02 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on 
the Dispatch Router on Linux

Hello Ganesh,

We are not in the stage of deploying multiple dispatch routers yet.

However may I know why you think this is the cause of the below failure?

Regards,
Adel

Get Outlook for Android<https://aka.ms/ghei36>


From: Ganesh Murthy
Sent: Wednesday, February 1, 13:06
Subject: Re: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on 
the Dispatch Router on Linux
To: users@qpid.apache.org

Hi Adel, Why is your router mode set to 'interior'? Do you have more than one 
router involved? If not, the mode should be set to 'standalone'. Thanks. - 
Original Message ----- > From: "Adel Boutros" > To: users@qpid.apache.org > 
Sent: Wednesday, February 1, 2017 6:55:35 AM > Subject: Re: [Dispatch router 
0.7.0] [Proton 0.16.0] SSL commands failing on the Dispatch Router on Linux > > 
Correction to the original mail: > If I remove any of the commands, the last 
command no longer fail. > > ____ > From: Adel 
Boutros > Sent: Wednesday, February 1, 2017 12:35:35 PM > To: 
users@qpid.apache.org > Subject: Re: [Dispatch router 0.7.0] [Proton 0.16.0] 
SSL commands failing on > the Dispatch Router on Linux > > > Re-attaching the 
dispatch router log. > >  > From: Adel Boutros 
> Sent: Wednesday, February 1, 2017 12:10:45 PM > To: users@qpid.apache.org > 
Subject: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the > 
Dispatch Router on Linux > > > Hello, > > > We have launched our test suite on 
the dispatch router 0.7.0 and noticed that > connections on a Listener 
configured with SASL External was not working > anymore. > > > With the below 
configuration and script, we have this exception ('SSL > Failure: Unknown 
error.') which keeps occurring. > > If I remove any of the commands except the 
one failing, the last one fails. > It seems we need to query the Dispatch 
router once and create 2 entities on > it for the 4th operation to fail. If I 
replace the "create" commands by > "delete" operation it doesn't seem to fail. 
> > > PS: All certificates used here are taken from the qpid-dispatch 
repository > here 
https://github.com/apache/qpid-dispatch/tree/0.7.0/tests/ssl_certs > > > > 
Exception client-side > > --- > > ConnectionException: 
Connection amqps://green-lx-slave1:10498/$management > disconnected: 
Condition('amqp:connection:framing-error', 'SSL Failure: > Unknown error.') > > 
> Router config > > - > > container { > worker-threads: 
4 > containerName: qpid.dispatch.router.10501 > } > > sslProfile { > keyFile: 
server-private-key.pem > password: server-password > certFile: 
server-certificate.pem > name: ssl-test-profile > certDb: ca-certificate.pem > 
} > > listener { > host: 0.0.0.0 > port: 10498 > saslMechanisms: EXTERNAL > 
sslProfile: ssl-test-profile > authenticatePeer: yes > requireSsl: yes > } > > 
router { > mode: interior > routerId: router.10501 > } > > log { > module: 
DEFAULT > enable: trace+ > source: false > output: dispatch.10501.log > } > > > 
Commands to launch in the below order > > 
 > > * Restart Dispatch 
Router > > > * Restart Broker > > > * qdstat -g -b amqp://localhost:10501 > > * 
qdmanage --ssl-trustfile=ca-certificate.pem > 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem > 
--ssl-password=client-password --ssl-disable-peer-name-verify -b > 
amqps://localhost:10498 create --type=address prefix=cluster.SSLMutualQueue > 
waypoint=true name=cluster.SSLMutualQueue.addr > > * qdmanage 
--ssl-trustfile=ca-certificate.pem > --ssl-certificate=client-certificate.pem 
--ssl-key=client-private-key.pem > --ssl-password=client-password 
--ssl-disable-peer-name-verify -b > amqps://localhost:10498 create 
--type=connector role=route-container > addr=localhost port=10305 
name=localhost.10305.connector > sslProfile=ssl-test-profile verifyHostName=no 
> > * (Failing command) qdmanage --ssl-trustfile=ca-certificate.pem > 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem > 
--ssl-password=client-password --ssl-disable-peer-name-verify -b > 
amqps://localhost:10498 delete --type=autoLink --name > 
localhost.10305.cluster.SSLMutualQueue.in > > Dispatch Router log > 
--- > See attached file > > Regards, > Adel > > 
- To 
unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, 
e-mail: users-h...@qpid.apache.org

Re: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the Dispatch Router on Linux

[Adel Boutros]

Hello Ganesh,

We are not in the stage of deploying multiple dispatch routers yet.

However may I know why you think this is the cause of the below failure?

Regards,
Adel

Get Outlook for Android<https://aka.ms/ghei36>


From: Ganesh Murthy
Sent: Wednesday, February 1, 13:06
Subject: Re: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on 
the Dispatch Router on Linux
To: users@qpid.apache.org

Hi Adel, Why is your router mode set to 'interior'? Do you have more than one 
router involved? If not, the mode should be set to 'standalone'. Thanks. - 
Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > 
Sent: Wednesday, February 1, 2017 6:55:35 AM > Subject: Re: [Dispatch router 
0.7.0] [Proton 0.16.0] SSL commands failing on the Dispatch Router on Linux > > 
Correction to the original mail: > If I remove any of the commands, the last 
command no longer fail. > > ________ > From: Adel 
Boutros > Sent: Wednesday, February 1, 2017 12:35:35 PM > To: 
users@qpid.apache.org > Subject: Re: [Dispatch router 0.7.0] [Proton 0.16.0] 
SSL commands failing on > the Dispatch Router on Linux > > > Re-attaching the 
dispatch router log. > >  > From: Adel Boutros 
> Sent: Wednesday, February 1, 2017 12:10:45 PM > To: users@qpid.apache.org > 
Subject: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the > 
Dispatch Router on Linux > > > Hello, > > > We have launched our test suite on 
the dispatch router 0.7.0 and noticed that > connections on a Listener 
configured with SASL External was not working > anymore. > > > With the below 
configuration and script, we have this exception ('SSL > Failure: Unknown 
error.') which keeps occurring. > > If I remove any of the commands except the 
one failing, the last one fails. > It seems we need to query the Dispatch 
router once and create 2 entities on > it for the 4th operation to fail. If I 
replace the "create" commands by > "delete" operation it doesn't seem to fail. 
> > > PS: All certificates used here are taken from the qpid-dispatch 
repository > here 
https://github.com/apache/qpid-dispatch/tree/0.7.0/tests/ssl_certs > > > > 
Exception client-side > > --- > > ConnectionException: 
Connection amqps://green-lx-slave1:10498/$management > disconnected: 
Condition('amqp:connection:framing-error', 'SSL Failure: > Unknown error.') > > 
> Router config > > - > > container { > worker-threads: 
4 > containerName: qpid.dispatch.router.10501 > } > > sslProfile { > keyFile: 
server-private-key.pem > password: server-password > certFile: 
server-certificate.pem > name: ssl-test-profile > certDb: ca-certificate.pem > 
} > > listener { > host: 0.0.0.0 > port: 10498 > saslMechanisms: EXTERNAL > 
sslProfile: ssl-test-profile > authenticatePeer: yes > requireSsl: yes > } > > 
router { > mode: interior > routerId: router.10501 > } > > log { > module: 
DEFAULT > enable: trace+ > source: false > output: dispatch.10501.log > } > > > 
Commands to launch in the below order > > 
 > > * Restart Dispatch 
Router > > > * Restart Broker > > > * qdstat -g -b amqp://localhost:10501 > > * 
qdmanage --ssl-trustfile=ca-certificate.pem > 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem > 
--ssl-password=client-password --ssl-disable-peer-name-verify -b > 
amqps://localhost:10498 create --type=address prefix=cluster.SSLMutualQueue > 
waypoint=true name=cluster.SSLMutualQueue.addr > > * qdmanage 
--ssl-trustfile=ca-certificate.pem > --ssl-certificate=client-certificate.pem 
--ssl-key=client-private-key.pem > --ssl-password=client-password 
--ssl-disable-peer-name-verify -b > amqps://localhost:10498 create 
--type=connector role=route-container > addr=localhost port=10305 
name=localhost.10305.connector > sslProfile=ssl-test-profile verifyHostName=no 
> > * (Failing command) qdmanage --ssl-trustfile=ca-certificate.pem > 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem > 
--ssl-password=client-password --ssl-disable-peer-name-verify -b > 
amqps://localhost:10498 delete --type=autoLink --name > 
localhost.10305.cluster.SSLMutualQueue.in > > Dispatch Router log > 
--- > See attached file > > Regards, > Adel > > 
- To 
unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, 
e-mail: users-h...@qpid.apache.org

Re: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the Dispatch Router on Linux

[Adel Boutros]

Correction to the original mail:
If I remove any of the commands, the last command no longer fail.


From: Adel Boutros <adelbout...@live.com>
Sent: Wednesday, February 1, 2017 12:35:35 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on 
the Dispatch Router on Linux


Re-attaching the dispatch router log.


From: Adel Boutros <adelbout...@live.com>
Sent: Wednesday, February 1, 2017 12:10:45 PM
To: users@qpid.apache.org
Subject: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the 
Dispatch Router on Linux


Hello,


We have launched our test suite on the dispatch router 0.7.0 and noticed that 
connections on a Listener configured with SASL External was not working anymore.


With the below configuration and script, we have this exception ('SSL Failure: 
Unknown error.') which keeps occurring.

If I remove any of the commands except the one failing, the last one fails. It 
seems we need to query the Dispatch router once and create 2 entities on it for 
the 4th operation to fail. If I replace the "create" commands by "delete" 
operation it doesn't seem to fail.


PS: All certificates used here are taken from the qpid-dispatch repository here 
https://github.com/apache/qpid-dispatch/tree/0.7.0/tests/ssl_certs



Exception client-side

---

ConnectionException: Connection amqps://green-lx-slave1:10498/$management 
disconnected: Condition('amqp:connection:framing-error', 'SSL Failure: Unknown 
error.')


Router config

-

container {
worker-threads: 4
containerName: qpid.dispatch.router.10501
}

sslProfile {
keyFile: server-private-key.pem
password: server-password
certFile: server-certificate.pem
name: ssl-test-profile
certDb: ca-certificate.pem
}

listener {
host: 0.0.0.0
port: 10498
saslMechanisms: EXTERNAL
sslProfile: ssl-test-profile
authenticatePeer: yes
requireSsl: yes
}

router {
mode: interior
routerId: router.10501
}

log {
module: DEFAULT
enable: trace+
source: false
output: dispatch.10501.log
}


Commands to launch in the below order



* Restart Dispatch Router


* Restart Broker


* qdstat -g -b amqp://localhost:10501

* qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 create --type=address prefix=cluster.SSLMutualQueue 
waypoint=true name=cluster.SSLMutualQueue.addr

* qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 create --type=connector role=route-container 
addr=localhost port=10305 name=localhost.10305.connector 
sslProfile=ssl-test-profile verifyHostName=no

* (Failing command) qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 delete --type=autoLink --name 
localhost.10305.cluster.SSLMutualQueue.in

Dispatch Router log
---
See attached file

Regards,
Adel

Re: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the Dispatch Router on Linux

[Adel Boutros]

Re-attaching the dispatch router log.


From: Adel Boutros <adelbout...@live.com>
Sent: Wednesday, February 1, 2017 12:10:45 PM
To: users@qpid.apache.org
Subject: [Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the 
Dispatch Router on Linux


Hello,


We have launched our test suite on the dispatch router 0.7.0 and noticed that 
connections on a Listener configured with SASL External was not working anymore.


With the below configuration and script, we have this exception ('SSL Failure: 
Unknown error.') which keeps occurring.

If I remove any of the commands except the one failing, the last one fails. It 
seems we need to query the Dispatch router once and create 2 entities on it for 
the 4th operation to fail. If I replace the "create" commands by "delete" 
operation it doesn't seem to fail.


PS: All certificates used here are taken from the qpid-dispatch repository here 
https://github.com/apache/qpid-dispatch/tree/0.7.0/tests/ssl_certs



Exception client-side

---

ConnectionException: Connection amqps://green-lx-slave1:10498/$management 
disconnected: Condition('amqp:connection:framing-error', 'SSL Failure: Unknown 
error.')


Router config

-

container {
worker-threads: 4
containerName: qpid.dispatch.router.10501
}

sslProfile {
keyFile: server-private-key.pem
password: server-password
certFile: server-certificate.pem
name: ssl-test-profile
certDb: ca-certificate.pem
}

listener {
host: 0.0.0.0
port: 10498
saslMechanisms: EXTERNAL
sslProfile: ssl-test-profile
authenticatePeer: yes
requireSsl: yes
}

router {
mode: interior
routerId: router.10501
}

log {
module: DEFAULT
enable: trace+
source: false
output: dispatch.10501.log
}


Commands to launch in the below order



* Restart Dispatch Router


* Restart Broker


* qdstat -g -b amqp://localhost:10501

* qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 create --type=address prefix=cluster.SSLMutualQueue 
waypoint=true name=cluster.SSLMutualQueue.addr

* qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 create --type=connector role=route-container 
addr=localhost port=10305 name=localhost.10305.connector 
sslProfile=ssl-test-profile verifyHostName=no

* (Failing command) qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 delete --type=autoLink --name 
localhost.10305.cluster.SSLMutualQueue.in

Dispatch Router log
---
See attached file

Regards,
Adel

Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: LogEntity(enable=trace+, 
identity=log/DEFAULT, module=DEFAULT, name=log/DEFAULT, 
output=/dispatch.10501.log, source=False, timestamp=True, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
type=org.apache.qpid.dispatch.log)
Wed Feb  1 11:54:52 2017 AGENT (debug) Add entity: 
LogEntity(identity=log/MESSAGE, module

Re: [Qpid Java Broker 6.0.4][Qpid JMS 0.11.1] Setting SSL options to AMQP non secured port triggers exception in JMS

[Adel Boutros]

Understood. Thanks!


Adel


From: Rob Godfrey <rob.j.godf...@gmail.com>
Sent: Wednesday, February 1, 2017 12:08:02 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker 6.0.4][Qpid JMS 0.11.1] Setting SSL options to 
AMQP non secured port triggers exception in JMS

So - bearing in mind that I was not involved (except very slightly) in the
development of this component, the general reason to throw an exception
rather than to ignore is in case the application programmer has made a
typo, or is expecting some behaviour by setting the option... and the fact
that no action will be taken (because of a typo, or because the option has
no effect in the context) will be a surprise to them.

So, if - for example - you were using an SSL connection, but had supplied
the option verfyHost=false (i.e. you had accidentally omitted the i in
verify) then it seems appropriate to throw the exception.

Ideally a better error message could be generated to differentiate between
completely unknown (and thus likely typos) options, and options that are
not valid on this transport (e.g. verifyHost on a non TLS connection), but
overall I think the decision to throw an exception is reasonable.

-- Rob

On 1 February 2017 at 11:57, Adel Boutros <adelbout...@live.com> wrote:

> So for me there are 2 possible solutions:
>
> 1) Throw exception
>
> 2 ) Ignore the useless parameters
>
>
> So for my general knowledge, why do you think the first one (Which is
> implemented in the JMS client) is the appropriate one?
>
>
> Regards,
>
> Adel
>
> 
> From: Robbie Gemmell <robbie.gemm...@gmail.com>
> Sent: Wednesday, February 1, 2017 11:47:00 AM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker 6.0.4][Qpid JMS 0.11.1] Setting SSL options
> to AMQP non secured port triggers exception in JMS
>
> Yep, the client is reporting that a given transport option was not
> able to be applied, in this case because its still using the 'tcp
> transport' and the verifyHost option only applies with the 'ssl
> transport'. As you thought, this occurs before it even attempts to
> make a connection.
>
> Robbie
>
> On 1 February 2017 at 10:35, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> > I'm not an expert on the JMS client, but I'm not sure that the
> "verifyHost"
> > option would make any sense on a non-TLS connection (since by definition
> > you can only verify the host when you receive the TLS certificate).
> >
> > I think the use of the Java Broker here is not important, as I assume
> this
> > fails before it even tries to make a connection,
> >
> > -- Rob
> >
> > On 1 February 2017 at 11:31, Adel Boutros <adelbout...@live.com> wrote:
> >
> >> Hello,
> >>
> >>
> >> I was playing around SSL/SASL with the Java Broker and noticed that some
> >> of the options which I can pass to the JMS client do not work.
> >>
> >>
> >> For example, if I set the following url for the JMS Connection Factory,
> I
> >> will get the below exception. Is this expected behavior?
> >>
> >>
> >> JmsConnectionFactory jmsConnectionFactory = new
> >> JmsConnectionFactory("amqp://localhost:5672?transport.
> verifyHost=false");
> >> jmsConnectionFactory.createConnection();
> >>
> >>
> >> Caused by: java.lang.IllegalArgumentException:  Not all transport
> options
> >> could be set on the TCP Transport. Check the options are spelled
> correctly.
> >> Unused parameters=[{verifyHost=false}]. This provider instance cannot
> be
> >> started.
> >> at org.apache.qpid.jms.transports.TransportFactory.createTransport(
> >> TransportFactory.java:64)
> >> at org.apache.qpid.jms.transports.TransportFactory.
> >> create(TransportFactory.java:120)
> >> at org.apache.qpid.jms.provider.amqp.AmqpProvider.connect(
> >> AmqpProvider.java:160)
> >>
> >>
> >> Regards,
> >>
> >> Adel
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

[Dispatch router 0.7.0] [Proton 0.16.0] SSL commands failing on the Dispatch Router on Linux

[Adel Boutros]

Hello,


We have launched our test suite on the dispatch router 0.7.0 and noticed that 
connections on a Listener configured with SASL External was not working anymore.


With the below configuration and script, we have this exception ('SSL Failure: 
Unknown error.') which keeps occurring.

If I remove any of the commands except the one failing, the last one fails. It 
seems we need to query the Dispatch router once and create 2 entities on it for 
the 4th operation to fail. If I replace the "create" commands by "delete" 
operation it doesn't seem to fail.


PS: All certificates used here are taken from the qpid-dispatch repository here 
https://github.com/apache/qpid-dispatch/tree/0.7.0/tests/ssl_certs



Exception client-side

---

ConnectionException: Connection amqps://green-lx-slave1:10498/$management 
disconnected: Condition('amqp:connection:framing-error', 'SSL Failure: Unknown 
error.')


Router config

-

container {
worker-threads: 4
containerName: qpid.dispatch.router.10501
}

sslProfile {
keyFile: server-private-key.pem
password: server-password
certFile: server-certificate.pem
name: ssl-test-profile
certDb: ca-certificate.pem
}

listener {
host: 0.0.0.0
port: 10498
saslMechanisms: EXTERNAL
sslProfile: ssl-test-profile
authenticatePeer: yes
requireSsl: yes
}

router {
mode: interior
routerId: router.10501
}

log {
module: DEFAULT
enable: trace+
source: false
output: dispatch.10501.log
}


Commands to launch in the below order



* Restart Dispatch Router


* Restart Broker


* qdstat -g -b amqp://localhost:10501

* qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 create --type=address prefix=cluster.SSLMutualQueue 
waypoint=true name=cluster.SSLMutualQueue.addr

* qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 create --type=connector role=route-container 
addr=localhost port=10305 name=localhost.10305.connector 
sslProfile=ssl-test-profile verifyHostName=no

* (Failing command) qdmanage --ssl-trustfile=ca-certificate.pem 
--ssl-certificate=client-certificate.pem --ssl-key=client-private-key.pem 
--ssl-password=client-password --ssl-disable-peer-name-verify -b 
amqps://localhost:10498 delete --type=autoLink --name 
localhost.10305.cluster.SSLMutualQueue.in

Dispatch Router log
---
See attached file

Regards,
Adel


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org