Re: [VOTE] Release Apache Qpid JMS 0.48.0

[Keith W]

On Fri, 6 Dec 2019 at 20:46, Timothy Bish  wrote:
>
> On 12/6/19 12:39 PM, Robbie Gemmell wrote:
> > Hi folks,
> >
> > I have put together a spin for a 0.48.0 Qpid JMS client release,
> > please give it a test out and vote accordingly.

+1

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 11.0.2 on Mac OS X 10.13.6)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the staged Maven artefacts



> >
> > The source and binary archives can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.48.0-rc1/
> >
> > The maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1188
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12346475
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test it out using maven (e.g with the examples
> > src, or your own things), you can temporarily add this to your poms to
> > access the staging repo:
> >
> >
> >  
> >staging
> >
> > https://repository.apache.org/content/repositories/orgapacheqpid-1188
> >  
> >
> >
> > The dependency for the client itself would then be:
> >
> >
> >  org.apache.qpid
> >  qpid-jms-client
> >  0.48.0
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
>
> +1
>
> * Validated signatures and checksums
> * Checked for License and Notice files
> * Checked source for license headers with 'mvn apache-rat:check'
> * Built from source and ran all tests
> * Built ActiveMQ 5.x and ran the AMQP tests
> * Built ActiveMQ Artemis and ran the AMQP integration tests.
>
>
> --
> Tim Bish
>
>
> -
> 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 Qpid Broker-J 7.1.5

[Keith W]

+1.

My testing was:

1) Verified the sha512 checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Reviewed NOTICE/LICENSE files.
4) Ran apache RAT
5) Built from source bundle and ran test profiles: mms with AMQP1.0
6) Spun up a Broker from the binary distribution

On Wed, 9 Oct 2019 at 16:08, Oleksandr Rudyy  wrote:
>
> Hi Robbie,
>
> Thanks for reporting the issue with failing test
> PreemptiveAuthenticationTest#clientAuthUnrecognisedCert on JDK 11 when TLS
> 1.3 is used.
> I missed this problem on both master and 7.1.x branches due to using Oracle
> JDKs in my tests. The issue manifests only with OpenJDK 11 and above. The
> test is passing with Oracle JDK 11.
>
> I briefly debugged the problem and came to conclusion that OpenJDK has some
> sort of race condition in implementation of  TLS 1.3 which results in
> SslException (in response to SocketException) being thrown instead of
> SslHandshakeException (after closing the socket on server side, the client
> part misses to detect that and tries to flush the output stream).
>
> I fixed the failing test and modified Travis config to build project with
> OpenJDK11 on master and 7.1.x branches. The Travis is currently building
> broker successfully on master and 7.1.x branches using openjdk8 and
> openjdk11.
> The Apache Jenkins instances are very slow and their environment is
> unstable. The builds are failing too often due to various environmental
> issues. Thus, I would like to avoid adding another job for 7.1.x and
> Java11, as Java8 is a primary JDK for 7.1 and  corresponding Jenkins job
> already exists.
>
> I agree, that the reported issue is not a show-stopper.
>
> Kind Regards,
> Alex
>
>
> On Wed, 9 Oct 2019 at 11:03, Robbie Gemmell 
> wrote:
>
> > +1
> >
> > I checked things out like so:
> > - Verified the signature + checksum files.
> > - Used mvn apache-rat:check to verify headers in the source archive.
> > - Checked for LICENCE + NOTICE files present in the archives.
> > - Started a broker from the binary archive, created queue using the
> > console.
> > - Ran the Qpid JMS 0.46.0 HelloWorld example against the broker.
> > - Ran build+tests with "mvn clean verify -DskipITs=false" on JDK8, no
> > issues.
> >
> > I also ran build+tests on JDK11, and I saw a test failure in HTTP
> > management systest
> > PreemptiveAuthenticationTest#clientAuthUnrecognisedCert. The test is
> > allowing for an SSLHandshakeException or SocketException to occur when
> > it fails to connect (as is expected), but here I see a base
> > SSLException caused by a SocketException, so it escapes the catch.
> > Trying 7.1.4 doesnt show the same, so I expect the newly enabled use
> > of TLS 1.3 on JDK 11 would be the difference as it can alter the
> > behaviour/timing slightly. Since you must explicitly opt in to run
> > these tests and the vote is a few days old rather than just started,
> > I'm not going to suggest this is a reason to respin at this stage, but
> > it should be fixed for the next one.
> >
> > Aside, I'm not seeing CI jobs covering 7.1.x for JDK11, only master
> > (on Jenkins, though not running this test), though the branches are
> > obviously pretty similar given their relation/usage. I'd suggest
> > expanding the Travis config on master+7.1.x to cover 11 as well.
> >
> > Robbie
> >
> > On Sun, 6 Oct 2019 at 11:54, Oleksandr Rudyy  wrote:
> > >
> > > Hi folks,
> > >
> > > I built release artefacts for Qpid Broker-J version 7.1.5 RC1.
> > > Please, give them a test out and vote accordingly.
> > >
> > > The source and binary archives can be found at:
> > > https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.1.5-rc1/
> > >
> > > The maven artifacts are also staged at:
> > > https://repository.apache.org/content/repositories/orgapacheqpid-1184
> > >
> > > The new version brings a number of improvements and bug fixes.
> > > You can find the full list of JIRAs included into the release here:
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12345734
> > >
> > > Kind Regards,
> > > Alex
> > >
> > > P.S. For testing of maven broker staging repo artefacts, please add into
> > to
> > > your project pom the staging repo as below:
> > >
> > > 
> > > 
> > >   staging
> > >   
> > > https://repository.apache.org/content/repositories/orgapacheqpid-1184
> > 
> > > 
> > > 
> > >
> > > -
> > > 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: [DISCUSS] Configure description, homepage, and labels (tags) for qpid repos on GitHub

[Keith W]

On Sat, 28 Sep 2019 at 21:32, Jiri Daněk  wrote:
>
> Hi folks,
>
> a while ago, support for .asf.yaml config file was announced by the Apache
> Infra team. This file, when placed in the root of a project repository,
> configures various infrastructure settings which were previously handled
> only by raising support tickets. One of those settings concerns the GitHub
> repository metadata of the project.
>
> Project description, homepage, and labels (tags) can be configured.
>
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Githubrepositorymeta-data
>
> I've created initial proposal for such file for qpid-proton
>
> https://github.com/apache/qpid-proton/pull/193
>
> The proposed .asf.yaml says

+1

>
> ```
> github:
>   description: "Mirror of Apache Qpid Proton"
>   homepage: https://qpid.apache.org/proton
>   labels:
> - qpid
> - amqp
> - messaging
> - library
> - apache
>
> - amqp-client
> - amqp-connection
> - amqp-messages
> - amqps
> - amqp10
>
> - c
> - cpp
> - golang
> - ruby
> - python
> - python2
> - python3
> ```
>
> Current values for these fields can be seen at the repo GitHub page
>
> https://github.com/apache/qpid-proton
>
> I'd be interested in any feedback about the description and labels fields.
> --
> Mit freundlichen Grüßen / Kind regards
> Jiri Daněk

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

Re: [VOTE] Release Apache Qpid JMS 0.44.0

[Keith W]

On Fri, 28 Jun 2019 at 21:27, Timothy Bish  wrote:
>
> On 6/28/19 2:01 PM, Robbie Gemmell wrote:
> > Hi folks,
> >
> > I have put together a spin for a 0.44.0 Qpid JMS client release,
> > please give it a test out and vote accordingly.

+1

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_171 and 11.0.2 on Mac OS X 10.14.5)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the staged Maven artefacts


> >
> > The source and binary archives can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.44.0-rc1/
> >
> > The maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1178
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12345616
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test it out using maven (e.g with the examples
> > src, or your own things), you can temporarily add this to your poms to
> > access the staging repo:
> >
> >
> >  
> >staging
> >
> > https://repository.apache.org/content/repositories/orgapacheqpid-1178
> >  
> >
> >
> > The dependency for the client itself would then be:
> >
> >
> >  org.apache.qpid
> >  qpid-jms-client
> >  0.44.0
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>
> +1
>
> * Validated signatures and checksums
> * Checked for LICENSE and NOTICE files in archives
> * Checked source for license headers with 'mvn apache-rat:check'
> * Built from source and ran all tests
> * Built ActiveMQ 5 with staged artifacts and ran all AMQP tests.
> * Built ActiveMQ Artemis with staged artifacts and ran the AMQP test suite
> * Ran the example from the client against a running Artemis broker install.
>
>
> --
> Tim Bish
>
>
> -
> 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 JMS 0.43.0

[Keith W]

+1

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_191 on Mac OS X 10.13.6)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the staged Maven artefacts

On Wed, 5 Jun 2019 at 12:29, Oleksandr Rudyy  wrote:
>
> +1
>
> * verified checksums and signatures
> * built and ran tests successfully from source bundle
> * ran successfully Qpid Broker-J integration tests on master using staged
> artefacts
>
>
> On Tue, 4 Jun 2019 at 13:09, Robbie Gemmell 
> wrote:
>
> > Hi folks,
> >
> > I have put together a spin for a 0.43.0 Qpid JMS client release,
> > please give it a test out and vote accordingly.
> >
> > The source and binary archives can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.43.0-rc1/
> >
> > The maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1177
> >
> > The JIRAs assigned are:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12345485
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test it out using maven (e.g with the examples
> > src, or your own things), you can temporarily add this to your poms to
> > access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1177
> > 
> > 
> >   
> >
> > The dependency for the client itself would then be:
> >
> >   
> > org.apache.qpid
> > qpid-jms-client
> > 0.43.0
> >   
> >
> > -
> > 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-J 0.33.1

[Keith W]

+1

My testing was:

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built from source / ran tests on Mac OS X 10.13.6 on Open JDK 11 and
Oracle JDK 1.8
* Ran Qpid Broker-J  (master - 71a37b) client integration tests using
the staged Proton-J artefacts.

On Thu, 30 May 2019 at 22:22, Timothy Bish  wrote:
>
> On 5/30/19 2:02 PM, Robbie Gemmell wrote:
> > Hi folks,
> >
> > I have put together a spin for a Qpid Proton-J 0.33.1 release, please
> > test it and vote accordingly.
> >
> > The files can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.33.1-rc1/
> >
> > The maven artifacts are staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1176
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12345452
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test things out using maven with your own build
> > you can temporarily add this to your poms to access the staging repo:
> >
> >
> >  
> >staging
> >
> > https://repository.apache.org/content/repositories/orgapacheqpid-1176
> >  
> >
> >
> > The dependency for proton-j would then be:
> >
> >
> >  org.apache.qpid
> >  proton-j
> >  0.33.1
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>
> +1
>
> * Validated signatures and checksums
> * Checked for license and notice files
> * Built from source and ran the test suite
> * Checked source for license headers using 'mvn apache-rat:check'
> * Built Qpid JMS master using staged artifacts and ran the tests
> * Built ActiveMQ 5.x master using staged artifacts and ran the AMQP tests
> * Built ActiveMQ Artemis master using staged artifacts and ran the AMQP
> tests
>
>
> --
> Tim Bish
>
>
> -
> 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 Qpid Broker-J 7.1.3

[Keith W]

+1

My testing was:

1) Verified the sha512 checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Reviewed NOTICE/LICENSE files.
4) Ran apache RAT
5) Built from source bundle and ran test profile 'mms'/AMQP1.0 and
integration test suite.
6) Spun up a Broker from the binary distribution

On Mon, 13 May 2019 at 10:34, VERMEULEN Olivier
 wrote:
>
> +1
>
> Ran the Murex test suite and all is green.
>
> Olivier
>
> -Original Message-
> From: Oleksandr Rudyy 
> Sent: jeudi 9 mai 2019 00:24
> To: users@qpid.apache.org
> Subject: [VOTE] Release Qpid Broker-J 7.1.3
>
> Hi,
>
> I built release artefacts for Qpid Broker-J version 7.1.3 RC1.
> Please, give them a test out and vote accordingly.
>
> The source and binary archives can be found at:
> https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.1.3-rc1/
>
> The maven artifacts are also staged at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1174
>
> The new version incorporates a number of improvements and bug fixes.
> You can find the full list of JIRAs included into the release here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12345357
>
> Kind Regards,
> Alex
>
> P.S. For testing of maven broker staging repo artefacts, please add into to 
> your project pom the staging repo as below:
>
> 
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1174
> 
> 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional 
> commands, e-mail: users-h...@qpid.apache.org
> ***
> 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 authorized 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: [VOTE] Release Apache Qpid JMS 0.42.0

[Keith W]

+1

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_191 and 11.0.2 on Mac OS X 10.13.6)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the staged Maven artefacts

On Wed, 8 May 2019 at 12:35, Gordon Sim  wrote:
>
> On 07/05/2019 6:38 pm, Robbie Gemmell wrote:
> > Hi folks,
> >
> > I have put together a spin for a 0.42.0 Qpid JMS client release,
> > please give it a test out and vote accordingly.
> >
> > The source and binary archives can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.42.0-rc1/
>
> +1
>
> * verified signature and checksum, built from source including tests
> * ran helloworld example against
>- proton-python example broker
>- qpid-cpp broker
>- dispatch router
>
> -
> 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-J 0.33.0

[Keith W]

+1

My testing was:

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built from source / ran tests on Mac OS X 10.13.6 on Open JDK 11 and
Oracle JSK 1.8
* Ran Qpid Broker-J  (master - 71a37b5) client integration tests using
the staged proton artefacts and Qpid-JMS.



On Thu, 2 May 2019 at 10:57, Robbie Gemmell  wrote:
>
> On Wed, 1 May 2019 at 19:36, Robbie Gemmell  wrote:
> >
> > Hi folks,
> >
> > I have put together a spin for a Qpid Proton-J 0.33.0 release, please
> > test it and vote accordingly.
> >
> > The files can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.33.0-rc1/
> >
> > The maven artifacts are staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1172
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12345238
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test things out using maven with your own build
> > you can temporarily add this to your poms to access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1172
> > 
> >   
> >
> > The dependency for proton-j would then be:
> >
> >   
> > org.apache.qpid
> > proton-j
> > 0.33.0
> >   
>
> +1
>
> I checked things over as so:
> - Verified the signatures and checksum files.
> - Checked for LICENCE + NOTICE files in the archives.
> - Ran "mvn apache-rat:check" to verify the source archive licence headers.
> - Ran the build and tests on JDK8 & JDK11.
> - Ran Qpid JMS master build+tests on JDK8 & JDK11 using the staged proton-j.
> - Ran Qpid Broker-J master build+systests with above client (using JDK8).
> - Ran ActiveMQ 5 & Artemis master builds and AMQP tests using it (with JDK8).
> - Ran the Qpid JMS HelloWorld against Qpid Dispatch 1.7.0 and Broker-J 7.1.2.
>
> 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.27.1

[Keith W]

+1

Built from source bundle, verified checksum and signature and ran unit
tests on Mac OS X 10.13.6 .  No test failures.


On Tue, 16 Apr 2019 at 17:52, Roddie Kieley  wrote:
>
> +1
> Cloned the repo from gitbox, checked out 0.27.1-rc1
> Fedora 29
> - Built using via cmake ../qpid-proton
> - Ran tests via ctest -VV; all tests ran passed
>
> OSX 10.11.6 w/Xcode 7.3.1
> - As previously built using
> ccmake -DCMAKE_OSX_DEPLOYMENT_TARGET=10.11 -DBUILD_RUBY=NO ../qpid-proton
> as per travis setup
> - also disabled RUNTIME_CHECK as known issues on this platform; no issues
> seen on Travis OSX builds
> - Ran tests via ctest -VV; more limited set ran and all passed
> - Ran c examples broker, receive, send variants
> - Ran cpp examples broker, simple send and receive variants
>
>
> On Mon, Apr 15, 2019 at 3:12 PM Robbie Gemmell 
> wrote:
>
> > Hi folks,
> >
> > I have put together a spin for a Qpid Proton 0.27.1 release, please
> > give it a test out and vote accordingly.
> >
> > The files can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/proton/0.27.1-rc1/
> >
> > The JIRAs assigned are:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12345370
> >
> > It is tagged as 0.27.1-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-J 0.32.0

[Keith W]

+1

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built and ran tests from source bundle (openjdk version "11.0.2" Mac
OS X 10.13.6) with/without PN_TRACE_FRM set
* Ran Qpid Broker-J's JMS client integration test suites against Qpid JMS
Client 0.40.0 overridden with the staged proton artifact (mvn
integration-test -DskipTests -DskipITs=false) on jdk1.8.0_191.jdk

On Thu, 28 Mar 2019 at 10:59, Robbie Gemmell  wrote:
>
> On Wed, 27 Mar 2019 at 14:28, Robbie Gemmell  wrote:
> >
> > Hi folks,
> >
> > I have put together a spin for a Qpid Proton-J 0.32.0 release, please
> > test it and vote accordingly.
> >
> > The files can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.32.0-rc1/
> >
> > The maven artifacts are staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1169
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12344568
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test things out using maven with your own build
> > you can temporarily add this to your poms to access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1169
> > 
> >   
> >
> > The dependency for proton-j would then be:
> >
> >   
> > org.apache.qpid
> > proton-j
> > 0.32.0
> >   
>
> +1
>
> I checked things over as so:
> - Verified the signatures and checksums.
> - Checked LICENCE and NOTICE files in the archives.
> - Used "mvn apache-rat:check" to verify licence headers in source archive.
> - Ran the build+tests on JDK8 & JDK11.
> - Build+test Qpid JMS master+0.40.0 on JDK8 & 11, using staged proton-j bits.
> - Built Qpid Broker-J master with updated proton-j and client, ran systests.
> - Ran the ActiveMQ 5 + Artemis master builds and AMQP tests with staged bits.
>
> 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: [Broker-J] How to configure HTTPS

[Keith W]

Cyril

What exactly are you seeing?  Are you seeing error messages when you try
and connect a browser?

To set up TLS for the Broker,  you create a keystore containing your key
material, then assign this to the port(s) you desire.   You need to cause
the Broker to restart after changing an existing port.  This can be done
through the console or you can bounce the whole process.   You don’t need a
trust store on the Broker unless you want to use client certs. The
Broker reports the ports it listens to and the transports assign as it
comes up.  Check the qpid.log.

The broker’s documentation covers the concepts (see the sections on ports
and key stores), but unfortunately does provide a step by step recipe.

Hope this helps

Keith.



On Wed, 27 Mar 2019 at 17:27, Cyril Micoud  wrote:

> Hi all,
>
>
>
> I would like to enable HTTPS on my broker, but I don’t know how!?
>
> I have add new dedicated port, authentication provider, key store and
> trust store but without any success!
>
>
>
> One of you can help me or give me the best way to configure my Broker-J
> 7.1.1?
>
>
>
> Thank you by advance,
>
> Best regards,
>
>
>
> Cyril
>
>
>
>
>
> *Cyril MICOUD*
>
> Software Development Engineer
>
> σLink Team
>
>
>
>
>
> Office: +33 (0)4 76 33 59 88
>
> email: cmic...@vitechnology.com
>
> Skype: cyril.micoud_vitech
>
>
>
> [image: cid:image012.png@01D395F8.9761BF70]
>
>
>
> *Vi TECHNOLOGY*
>
> Rue de Rochepleine - 38120 SAINT EGREVE - France
>
> Further information at www.vitechnology.com
>
>
>
> You are hereby formally notified that all information contained in tis
> communication and any attachments shall be deemed strictly confidential and
> privileged unless explicitly stated otherwise. Please note that your use of
> confidential information may be governed, and restricted, by a
> non-disclosure agreement. The information contained in this communication
> and any attachments is disclosed for the sole use of the intended
> recipient(s). If you are not the intended recipient, you are hereby
> formally notified that any unauthorized review, use, disclosure or
> distribution of this message is prohibited. Please notify the sender
> immediately by replying to this message and destroy all copies of this
> message and any attachments. Mycronic is neither liable for the proper and
> complete transmission of the information contained in this communication,
> nor for any delay in its receipt. Please note that email correspondence
> generally includes processing of personal data. For information on
> Mycronic’s processing of your personal data, please see our Privacy Policy:
> http://www.mycronic.com/fr/about-us/privacy-policy/
>
>
>

Re: Welcome Jiri Danek as an Apache Qpid committer

[Keith W]

Indeed, welcome!

On Sat, 2 Mar 2019 at 21:08, Jiri Daněk  wrote:
>
> On Fri, Mar 1, 2019 at 11:12 AM Robbie Gemmell 
> wrote:
>
> > The Qpid PMC have voted to grant commit rights to Jiri Danek in
> > recognition of continued contributions to the project.
> >
> > Welcome, Jiri!
> >
> > Robbie
> >
>
> Hello everyone,
>
> thanks very much, glad to be on board!
> --
> Mit freundlichen Grüßen / Kind regards
> Jiri Daněk

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

Re: [VOTE] Release Qpid Broker-J 7.1.1

[Keith W]

+1.

My testing was:

1) Verified the sha512 checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Reviewed NOTICE/LICENSE files.
4) Ran apache RAT
5) Built from source bundle and ran test profiles: mms//bdb/dby with
AMQP1.0 and bdb with 0.10/0-9
6) Spun up a Broker from the binary distribution


On Tue, 26 Feb 2019 at 14:04, Rob Godfrey  wrote:
>
> +1 - built from source, ran tests (0-9-1, 0-10 mms; 1-0 bdb)
> verified signatures/checksums
> ad hoc testing
>
> On Tue, 26 Feb 2019 at 14:24, Gordon Sim  wrote:
>
> > On 26/02/2019 12:40 pm, Oleksandr Rudyy wrote:
> > > I expect that building and running tests for earlier versions of broker-j
> > > bundle would fail with the same error when OpenJDK 8u201 is used.
> >
> > This seems to be correct. I tried to run tests for 7.1.0 and got the
> > same errors though these had all passed when I tested that release (I
> > was on fedora 27 at that time).
> >
> > -
> > 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: Availability of holdOnPublishEnabled attribute in Qpid Broker-J 0.32

[Keith W]

On Tue, 12 Feb 2019 at 00:26, sidarthsc  wrote:
>
> Could you explain how the logic behind the holdOnPublishEnabled attribute
> works? For example, is there a thread that periodically iterates over all
> messages in queues for which this attribute is enabled and releases, or
> pushes those messages which are eligible for being processed?

It is the responsibility of the virtualhost housekeeper (see
VirtualHostHouseKeepingTask and
org.apache.qpid.server.queue.AbstractQueue#checkMessageStatus).  The
period with which the housekeeper runs is defined by
virtualhost.housekeepingCheckPeriod so a message may remain held of
the queue by virtualhost.housekeepingCheckPeriod ms too long.
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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.27.0

[Keith W]

+1

Built from source bundle, verified checksum and signature and ran unit
tests on Mac OS X 17.7.0.  No test failures.


On Thu, 7 Feb 2019 at 21:57, Chuck Rolke  wrote:
>
> +1
>
> * Built on Fedora 29, python 2
> * Ran self tests
> * Ran limited number of C examples stand-alone
> * Built with qpid-dispatch and passed dispatch self tests except 
> system_tests_ssl [1]
>
> [1] Dispatch relies on proton ssl version selection code which is suffering 
> from software rot.
> Please get this jira on the road map.
> https://issues.apache.org/jira/browse/PROTON-1989
>
>
> - Original Message -
> > From: "Timothy Bish" 
> > To: users@qpid.apache.org
> > Sent: Thursday, February 7, 2019 3:50:30 PM
> > Subject: Re: [VOTE] Release Apache Qpid Proton 0.27.0
> >
> > On 2/6/19 9:01 AM, Robbie Gemmell wrote:
> > > Hi folks,
> > >
> > > I have put together a spin for a Qpid Proton 0.27.0 release, please
> > > give it a test out and vote accordingly.
> > >
> > > The files can be grabbed from:
> > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.27.0-rc1/
> > >
> > > The JIRAs assigned are:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12344242
> > >
> > > It is tagged as 0.27.0-rc1.
> > >
> > > Regards,
> > > Robbie
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > > For additional commands, e-mail: users-h...@qpid.apache.org
> > >
> > >
> > +1
> >
> > * Verified the signature and checksum files.
> > * Checked for LICENCE and NOTICE files in the archive.
> > * Built the library on Mint 19 and ran the test suite.
> > * Ran some of the examples against an Artemis broker.
> >
> > --
> > Tim Bish
> >
> >
> > -
> > 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: [Broker-J] non persistent messages

[Keith W]

Olivier

On Thu, 7 Feb 2019 at 12:47, VERMEULEN Olivier
 wrote:
>
> Alex,
>
> Actually I'm trying to find the easiest way to switch my existing performance 
> benchmark to use only non-persistent messages...

Take a look at Queue#messageDurability. It allows you to override
the sender application's preference for a message's durability.  If
you set NEVER, the message won't written to persistent store even if
the sender requested it.
All queues take their default from ${queue.defaultMessageDurability},
so unless are setting explicitly setting it on a queue, you can just
override from a higher level, for instance, as a system property.  It
won't affect messages that are already on the queue.

./bin/qpid-server -Dqueue.defaultMessageDurability=NEVER

Hope this helps




> And using a memory message store seemed like the best option.
> I'm just looking for a quick feedback on the kind of performance improvement 
> we could have.
>
> Olivier
>
> -Original Message-
> From: Oleksandr Rudyy 
> Sent: jeudi 7 février 2019 11:42
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] non persistent messages
>
> Olivier,
>
> You are right. The persistent messages are kept in memory with memory message 
> store. Please note, that with AMQP 1.0 an attempt to publish persistent 
> message on VH with memory store would end-up in error 
> "amqp:precondition-failed" - "Non-durable message store cannot accept durable 
> message."
> You can set JVM system property 'qpid.tests.mms.messagestore.persistence'
> to 'true' in order to allow persisting of AMQP 1.0 persistent messages into 
> memory store.
> Persisting of AMQP 0-x messages into memory store works straight away.
>
> Out of curiosity, what is you messaging use case? Why do you need to use 
> Memory message store?
>
> Kind Regards,
> Alex
>
>
> On Thu, 7 Feb 2019 at 10:20, VERMEULEN Olivier 
> wrote:
>
> > Hello Alex,
> >
> > Thanks for the clarification on the non-durable queues.
> > For the store I was talking about the message store, not the config one.
> > So I guess the memory message store would be equivalent to having all
> > messages non-persistent?
> >
> > Olivier
> >
> > -Original Message-
> > From: Oleksandr Rudyy 
> > Sent: jeudi 7 février 2019 10:29
> > To: users@qpid.apache.org
> > Subject: Re: [Broker-J] non persistent messages
> >
> > Hi Olivier,
> >
> > The non-durable queues are not stored in the configuration. Thus, on
> > broker restart they disappear with all  their messages regardless
> > whether they are persistent or not.
> > The Memory store was designed mainly for using in tests. All
> > configuration stored there is "persisted" into heap, and, thus, it
> > disappears on broker restart.
> >
> > Kind Regards,
> > Alex
> >
> >
> > On Thu, 7 Feb 2019 at 08:10, VERMEULEN Olivier <
> > olivier.vermeu...@murex.com>
> > wrote:
> >
> > > Hello,
> > >
> > > Just a quick question regarding the broker config.
> > > What's the difference between setting the message store to "Memory"
> > > and setting each queue as "non-durable"? or is it exactly the same thing?
> > >
> > > Thanks,
> > > 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 authorized 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.
> > >
> > ***
> > 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 authorized 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
> >
> >
> ***
> 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 authorized 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 

Re: [VOTE] Release Apache Qpid Proton-J 0.31.0

[Keith W]

+1.

My testing was:

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built from source / ran tests on Mac OS X 10.13.6
* Ran Qpid Broker-J client integration tests using the staged proton
artefacts with Qpid-JMS (0.38.0)
On Tue, 27 Nov 2018 at 11:27, Gordon Sim  wrote:
>
> On 23/11/18 16:01, Robbie Gemmell wrote:
> > Hi folks,
> >
> > I have put together a spin for a Qpid Proton-J 0.31.0 release, please
> > test it and vote accordingly.
>
> +1, built from source ensuring all tests passed
>
> -
> 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 JMS 0.38.0

[Keith W]

+1

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_181-b13 on Mac OS X 10.11.6)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the staged Maven artefacts


On Tue, 13 Nov 2018 at 10:38, Oleksandr Rudyy  wrote:
>
> +1
>
> * Validated signatures and checksums
> * Built from source and ran the test suite
> * Run successfully Qpid Broker-J system tests on master with staged
> qpid-jms-client 0.38.0 artefacts using profile java-mms.1-0
> On Mon, 12 Nov 2018 at 18:43, Robbie Gemmell  wrote:
> >
> > Hi folks,
> >
> > I have put together a spin for a 0.38.0 Qpid JMS client release,
> > please give it a test out and vote accordingly.
> >
> > The source and binary archives can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.38.0-rc1/
> >
> > The maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1161
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12344251
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test it out using maven (e.g with the examples
> > src, or your own things), you can temporarily add this to your poms to
> > access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1161
> > 
> >   
> >
> > The dependency for the client itself would then be:
> >
> >   
> > org.apache.qpid
> > qpid-jms-client
> > 0.38.0
> >   
> >
> > -
> > 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: [VOTE] Release Apache Qpid Proton-J 0.30.0

[Keith W]

+1.

My testing was:

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built from source / ran tests on Mac OS X 10.13.6
* Ran Qpid Broker-J client integration tests using the staged proton
artefacts and Qpid-JMS (master - 9c1afa9b3)
* Ran Qpid JMS test suite (master - 9c1afa9b3) using the staged proton artefacts
On Wed, 7 Nov 2018 at 16:33, Oleksandr Rudyy  wrote:
>
> +1
>
> Robbie, thanks for the detailed explanation about the nature of the
> issue with qpid-jms-client 0.36.0.
> I was able to run successfully Broker-J integration tests with
> qpid-jms-client 0.37.0 and proton-j 0.30.0 RC.
> Apart from running Qpid Broker-J integration tests I  verified
> signatures/checksums and built and ran tests successfully from
> proton-j 0.30.0 sources.
> On Wed, 7 Nov 2018 at 15:27, Robbie Gemmell  wrote:
> >
> > After some investigation I found this actually stems from a bug in the
> > older 0.36.0 qpid-jms client rather than in the proton-j 0.30.0 RC.
> > The client had a bug in its implementation of a buffer interface, one
> > which proton-j is now making use of in a way that exposes that bug in
> > the older client. The particular bug was already fixed in 0.37.0, so
> > using 0.37.0 or the 0.38.0-SNAPSHOT passes those tests, as did a
> > modified 0.36.0.
> >
> > While it might have been nice to avoid this until a future point,
> > given it was a client bug and the situation doesnt arise with the
> > current release I believe we should proceed as-is.
> >
> > Robbie
> >
> > On Wed, 7 Nov 2018 at 10:12, Oleksandr Rudyy  wrote:
> > >
> > > Hi,
> > >
> > > I tried to run Qpid Broker-J system tests with qpid-jms-client 0.36.0
> > > and staged org.apache.qpid:proton-j:0.30.0 but JMS 1.1 tests from
> > > suite org.apache.qpid.systests.jms_1_1.message.LargeMessageTest failed
> > > due to mismatch of received message text and sent message text.
> > > The text messages with sizes 245KB, 512KM and 1MB are sent and
> > > received as part of the test suite.
> > > Somehow  some characters at the end of the received messages have been
> > > replaced with '\u0' characters. The tests are passing with proton-j
> > > 0.29.0 and qpid-jms-client 0.36.0.
> > >
> > > Kind Regards,
> > > Alex
> > > On Tue, 6 Nov 2018 at 18:15, Robbie Gemmell  
> > > wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > I have put together a spin for a Qpid Proton-J 0.30.0 release, please
> > > > test it and vote accordingly.
> > > >
> > > > The files can be grabbed from:
> > > > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.30.0-rc1/
> > > >
> > > > The maven artifacts are staged for now at:
> > > > https://repository.apache.org/content/repositories/orgapacheqpid-1160
> > > >
> > > > The JIRAs assigned are:
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343875
> > > >
> > > > Regards,
> > > > Robbie
> > > >
> > > > P.S. If you want to test things out using maven with your own build
> > > > you can temporarily add this to your poms to access the staging repo:
> > > >
> > > >   
> > > > 
> > > >   staging
> > > >   
> > > > https://repository.apache.org/content/repositories/orgapacheqpid-1160
> > > > 
> > > >   
> > > >
> > > > The dependency for proton-j would then be:
> > > >
> > > >   
> > > > org.apache.qpid
> > > > proton-j
> > > > 0.30.0
> > > >   
> > > >
> > > > -
> > > > 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
> >
>
> -
> 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: High memory utilization with Java version of Qpid 7.0.6

[Keith W]

Hello

There is general advice [1] for tuning memory sizes and formulae to
help you size direct and heap memory appropriately for your use-case.

As you'll read, Broker-J keeps a message's payload and headers in
direct memory for performance reasons.  If direct memory comes under
pressure, it has an algorithm to evict the cached payload and headers
and write them to disk (if transient, persistent ones already are).
The use of direct memory was new with 6.0.0. In the heap, the Broker
maintains a linked list representing the entire queue.   This is a
light weight structure with pointers to the message.  The Broker
currently has no strategy to page out chunks of this linked list, so
it is possible just to exhaust heap by having a long queue.   This
aspect was exactly the same in 0.32 and below.   The Broker's defence
against this situation is producer flow control.  The controls for
this have become richer in the newer versions.

I am not certain that the graph that you share in itself actually
indicates a problem.   Might this not just be a normal saw-tooth GC
pattern?  Are you actually going OOME (heap).   There is heap garbage
created as messages traverse the Broker, so the JVM will collect this
when it sees fit.  You would have seen a similar pattern with 0.32 and
before.

Hope this helps

[1] 
https://qpid.apache.org/releases/qpid-broker-j-7.0.6/book/Java-Broker-Runtime-Memory.html
On Mon, 15 Oct 2018 at 21:01, Brian O'Shea  wrote:
>
> Hello Qpid Community,
>
> I am seeing some strange memory utilization patterns when running the Java
> implementation of Qpid, version 7.0.6 on Linux (Ubuntu 16.04).  I ran some
> tests for the application that I am working on that uses Qpid, which
> enqueues about 50 messages.  I see this very high memory usage by Qpid while
> running these tests (see attached image).
>
> My Qpid memory properties are set to the following:
>
> # Java heap settings
> qpid.java.min.memory = 3072m
> qpid.java.max.memory = 3072m
>
> qpid.java.direct.memory  = 9216m
> qpid.flow_to_disk_threshold = 6606029
>
> Several of our tests fail, but if I re-run them all, different ones will
> pass and fail, so I suspect it is related to when the memory utilization is
> high.  In production, we enqueue many more messages (millions per day), so I
> am concerned that with this version of Qpid and/or with this combination of
> memory settings, it may not scale.  Can you help me compute the optimal
> memory settings for this application?  Let me know if you need to know
> anything else about the way that we will be using Qpid.
>
> Thanks,
> Brian
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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 7.0.6 not listening on HTTPS port at startup

[Keith W]

Hello Brian

Check the log file (default location ${QPID_WORK}/log/qpid.log).
You'll probably see that the port has gone into an ERRORed state,
owing to the lack of a keystore object called "Selfsigned", which is
absent from your configuration file.  I suggest setting up the Broker
using the Console (or REST API) and comparing with the configuration
you are trying to craft by hand.

Keith.
On Wed, 10 Oct 2018 at 01:29, Brian O'Shea  wrote:
>
> Hello Qpid Community,
>
> I am trying to configure the Java Qpid broker (version 7.0.6) on Linux
> (Ubuntu 16.04) using OpenJDK 1.8.0 u162.  When I start the broker, it is not
> listening on the HTTPS port that I specified in the JSON configuration file.
> It is listening on the HTTP and AMPQ ports that I have configured.  I've
> attached our JSON configuration file for reference.
>
>
> /home/boshea/blt/tools/Linux/jdk/openjdk1.8.0_162_x64/bin/java -server
> -Xms500m -Xmx1024m -XX:MaxDirectMemorySize=250m -XX:+UseParallelOldGC
> -XX:+HeapDumpOnOutOfMemoryError -verbose:gc -XX:+PrintGCDetails
> -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps
> -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime
> -XX:-TraceClassUnloading
> -Xloggc:/home/boshea/blt/app/main/core/sfdc/qpid/logs/jvmgc.log
> -DPNAME=QPBRKR -DQPID_HOME=/home/boshea/blt/tools/qpid/v7.0.6
> -DQPID_WORK=/home/boshea/blt/app/main/core/sfdc/qpid
> -Dqpid.logfile.name=/home/boshea/blt/app/main/core/sfdc/qpid/logs/main.sfdc.localhost.qpid.broker.gmt.log
> -Dqpid.logging.level=WARN -Djava.rmi.server.hostname=127.0.0.1
> -Dqpid.flow_to_disk_threshold=209715200 -Dqpid.amqp_port=5672
> -Dqpid.http_port=5673 -Dqpid.https_port=5675 -Dqpid.rmi_port=8999
> -Dqpid.jmx_port=9099 -Dqpid.virtualhost_name=test
> -Dqpid.virtualhost_type=BDB -classpath
> /home/boshea/blt/app/main/core/build/ManifestJars/manifest-classpath_MAIN.qpid-start-java-java_4876430406122862138.jar
> org.apache.qpid.server.Main -sp
> /home/boshea/blt/app/main/core/sfdc/qpid/etc/sfdc-broker-configuration.json
> [Broker] BRK-1006 : Using configuration :
> /home/boshea/blt/app/main/core/sfdc/qpid/etc/sfdc-broker-configuration.json
> [Broker] BRK-1001 : Startup : Version: 7.0.6 Build:
> bda3e6d2254b1634256cf4e0d4eff4da549d3ed8
> [Broker] BRK-1010 : Platform : JVM : Azul Systems, Inc. version:
> 1.8.0_162-b01 OS : Linux version: 4.4.0-137-generic arch: amd64 cores: 16
> [Broker] BRK-1011 : Maximum Memory : Heap : 954,728,448 bytes Direct :
> 262,144,000 bytes
> [Broker] BRK-1017 : Process : PID : 31324
> [Broker] BRK-1002 : Starting : Listening on TCP port 5672
> [Broker] MNG-1001 : Web Management Startup
> [Broker] MNG-1002 : Starting : HTTP : Listening on TCP port 5673
> [Broker] MNG-1004 : Web Management Ready
> [Broker] BRK-1004 : Qpid Broker Ready
>
>
> sfdc-broker-configuration.json
> 
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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.26.0 (RC2)

[Keith W]

On Thu, 4 Oct 2018 at 13:35, Robbie Gemmell  wrote:
>
> Hi folks,
>
> I have put together a second spin for a Qpid Proton 0.26.0 release,
> please give it a test out and vote accordingly.

+1.

My testing was:

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built from source / ran tests on Mac OS X 10.13.6
* Ran hello world against Apache Qpid Broker-J (master)


>
> The files can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.26.0-rc2/
>
> The JIRAs assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12344005
>
> The changes since RC1 were made via PROTON-1946 and PROTON-1947 (fixup
> sub tasks for PROTON-1935).
>
> It is tagged as 0.26.0-rc2.
>
> 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: Converting Qpid Broker configuration from older versions to new

[Keith W]

Hello Brian,

For the most part of Broker-J will handle the upgrade of configuration
from 0.32 and any BDB message store automatically.  Take a backup of
the ${QPID_WORK} from your old Broker and start the new pointed at the
same location.   It will automatically rewrite the configuration and
message store as it comes up for the first time.   The upgrade is one
way so an upgraded configuration and message store cannot be used with
an older version of Broker-J.

One area of configuration that is not covered by automatic upgrade any
ACL rules.   If you are using ACLs, check the rules that you use
against the documentation.

One of the biggest differences between 0.32 and 7.0.x is the way the
Broker uses memory.  The 7.0.x Broker uses both heap and direct
memory, the latter being used to cache messages during their traversal
through the Broker.   The way the Broker uses memory is documented
[2].  You'll need to reevaluate any sizing decisions you made for the
old Broker.  There are formulae in the documentation to help you.

The other big area of change is the matured support for AMQP 1.0
available in Broker-J 7.0.x.AMQP 1.0 support was added alongside
the support for the older protocols (AMQP 0-9 and 0-10), so your
existing applications will continue to function without change.   You
will want to consider upgrading client applications to AMQP 1.0 based
libraries, but you don't need to conflate this with your broker
upgrade.Broker-J supports on the fly message translation so having
application A using say AMQP 0-10 and application B using AMQ 1.0 is
supported.  This can allow any upgrade to be phased.

Hope this helps

Keith.

[1] 
https://qpid.apache.org/releases/qpid-broker-j-7.0.6/book/Java-Broker-Security-AccessControlProviders.html#Java-Broker-Security-AccessControlProviders-ACLRules
[2] 
https://qpid.apache.org/releases/qpid-broker-j-7.0.6/book/Java-Broker-Runtime-Memory.htmlOn
Sat, 29 Sep 2018 at 01:48, Brian O'Shea  wrote:
>
> Hello,
>
> I am in the process of upgrading the Qpid Broker version that my
> organization is using from 0.32 to 7.0.6.  I know this is quite a big jump.
> A former employee already did some of the work to upgrade to 6.0.5, but we
> never finished the upgrade before he left, and now we want to upgrade to
> 7.0.6.  I mention this because we don't have adequate testing around the
> configuration for 6.0.5, so the most well-known, stable configuration that
> we have is for 0.32.
>
> Do you provide tools for converting the JSON configuration from older
> versions to newer versions?
>
> Thanks,
> Brian O'Shea
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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 JMS 0.37.0

[Keith W]

On Fri, 28 Sep 2018 at 18:32, Robbie Gemmell  wrote:
>
> Hi folks,
>
> I have put together a spin for a 0.37.0 Qpid JMS client release,
> please give it a test out and vote accordingly.
>

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_181 on Mac OS X 10.13.6)
* ran Broker-J's JMS integration test suite (mvn clean
verify-DskipTests=true -DskipITs=false) against the staged Maven
artefacts for both the memory and bdb profiles

> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/0.37.0-rc1/
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1159
>
> The JIRAs assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12343889
>
> Regards,
> Robbie
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1159
> 
>   
>
> The dependency for the client itself would then be:
>
>   
> org.apache.qpid
> qpid-jms-client
> 0.37.0
>   
>
> -
> 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 Qpid for Java 6.1.7

[Keith W]

On Tue, 28 Aug 2018 at 13:27, Oleksandr Rudyy  wrote:
>
> Hi all,
>
> I built a release candidate for 6.1.7 version of the Qpid for Java.
> Please give it a test out and vote accordingly.


+1.

My testing was:

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Ran apache RAT
* Built/ran test profile bdb/dby/mms (0-9/0-10) from source bundle
* Ran hello world against staged maven client artefacts against broker
from binary distribution artefact



>
> The list of defect fixes can be found in Jira:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12343003
>
> The source and binary archives can be grabbed from here:
> https://dist.apache.org/repos/dist/dev/qpid/java/6.1.7-rc1
>
> Those files and the other maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1158
>
> Kind regards,
> Alex
>
> P.S. If you want to test it out using maven (e.g with the examples src,
> or your own things), you can temporarily add this to your poms to access
> the staging repo:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1158
> 
>   
>
> -
> 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 Broker-J - VirtualHost logger...

[Keith W]

On Fri, 24 Aug 2018 at 14:13, Cyril Micoud  wrote:
>
> Hi,
>
>
>
> We can define two types of logger in virtualhost : File and Syslog
>
>
>
> For File logger:
>
> Can I download log files via REST api?
>
>

Yes, that is supported. The VirtualHostFileLogger object gives you, amongst
other attributes, an attribute logFiles that is a list the log files known
to the logger. It also gives you operations that get the contents of a
single log file (getFile), or a set of log files (getFiles), or all files
(getAllFiles).  The latter two return you a zip stream.  I give you a link
to the relevant parts of the documentation and a couple of example commands
to get you going.

# Assuming a virtualhost logger named mylogger and a virtualhostnode and
virtualhost named foo
curl --user admim
https://localhost:8080/api/latest/virtualhostlogger/foo/foo/mylogger
curl --user admin  --data '{"fileName" : "mylogger.log"}'
https://localhost:8080/api/latest/virtualhostlogger/foo/foo/mylogger/getFile

https://qpid.apache.org/releases/qpid-broker-j-7.0.6/book/Java-Broker-Management-Channel-REST-API.html

>
> Syslog provide an Host and a Port…
>
> So my question is:
>
> Is it possible to access/read syslog with a REST request?

The VirtualHostSyslogLogger simple forwards the log events to an external
syslog daemon that you provide.  You would then use whatever facilities
provided by the daemon to read/process those events.  You could look at
tools such as Splunk and Logstash both of which have the ability to receive
syslog events.


>
>
>
> Best regards,
>
>
>
> Cyril
>
>
>
>
>
> Cyril MICOUD
>
> Software Development Engineer
>
>
>
> Office : +33 (0)4 76 33 59 88
>
> email: cmic...@vitechnology.com
>
> Skype: cyril.micoud_vitech
>
>
>
>
>
> www.vitechnology.com
>
>
>
> Vi TECHNOLOGY - Rue Rochepleine - 38120 SAINT EGREVE - FRANCE
>
> Follow us on ,  and
>
>
>
> This message and any attachments are confidential and intended solely for
the addressees. Any unauthorized use or dissemination is prohibited.
E-mails are susceptible to alteration. VIT shall not be liable for the
message if altered, changed or falsified
>
>

Re: [VOTE] Release Apache Qpid JMS 0.36.0

[Keith W]

> > I have put together a spin for a 0.36.0 Qpid JMS client release,
> > please give it a test out and vote accordingly.

+1

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_171 on Mac OS X 10.11.6)
* ran Broker-J's JMS integration test suite (mvn clean
verify-DskipTests=true -DskipITs=false) against the staged Maven
artefacts
for both the memory and bdb profiles (the latter utilises failover
extensively during HA tests).   Needed to override Netty version (test
dependency) to match that used by the Qpid JMS Client (4.1.28.Final)

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

Re: [VOTE] Release Apache Qpid JMS AMQP 0-x 6.3.3

[Keith W]

+1
* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built and ran tests from source bundle (Java1.8.0_181-b13 Mac OS X 10.11.6)
* Ran Broker-J's JMS client integration test suites against the staged
Qpid JMS AMQP 0-x 6.3.3 (mvn integration-test -DskipTests
-DskipITs=false  -P java-mms.0-x [for both 0-9 and 0-10])
On Wed, 15 Aug 2018 at 22:44, Jakub Scholz  wrote:
>
> +1 ... I used the staged artifacts with AMQP 0-10 and run some of my tests
> against Qpid C++ broker.
>
> On Mon, Aug 13, 2018 at 7:22 PM Oleksandr Rudyy  wrote:
>
> > Hi,
> >
> > I built a candidate release for version 6.3.3 of Qpid JMS AMQP 0-x.
> > Please test and vote accordingly.
> >
> > The source and binary bundles can be taken from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms-amqp-0-x/6.3.3-RC1/
> >
> > The maven artifacts are also staged at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1156
> >
> > The JIRAs currently assigned are:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12343821
> >
> > Regards,
> > Alex
> >
> > P.S. If you want to test it out using maven, you can temporarily add this
> > to your project pom to access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1156
> > 
> > 
> >   
> >
> > The dependency for the client itself would then be:
> >
> >   
> > org.apache.qpid
> > qpid-client
> > 6.3.3
> >   
> >
> > -
> > 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-J 0.29.0

[Keith W]

+1
* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built and ran tests from source bundle (Java1.8.0_181-b13 Mac OS X 10.11.6)
* Ran Broker-J's JMS client integration test suites against Qpid JMS
Client 0.35.0 overridden with the staged proton artifact Qpid master
build (mvn integration-test -DskipTests -DskipITs=false)
On Mon, 13 Aug 2018 at 17:51, Oleksandr Rudyy  wrote:
>
> +1
>
> * verified signatures and checksums
> * built and ran tests from source bundle
> * ran Qpid Broker-J integration tests using staged maven artefacts
>
> On Fri, 10 Aug 2018 at 21:12, Robbie Gemmell  wrote:
> >
> > I have put together a spin for a Qpid Proton-J 0.29.0 release, please
> > test it and vote accordingly.
> >
> > The files can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.29.0-rc1/
> >
> > The maven artifacts are staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1155
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343803
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test things out using maven with your own build
> > you can temporarily add this to your poms to access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1155
> > 
> >   
> >
> > The dependency for proton-j would then be:
> >
> >   
> > org.apache.qpid
> > proton-j
> > 0.29.0
> >   
> >
> > -
> > 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: [DISCUSS] Ending support for Java 7 in Proton-J

[Keith W]

+1
On Wed, 8 Aug 2018 at 22:06, Timothy Bish  wrote:
>
> +1
>
> I'd be happy if we moved up to 8 and allow for usage of some of the APIs
> not available in 7
>
> On 08/08/2018 02:04 PM, Robbie Gemmell wrote:
> > I think this is probably as much a notice as a discussion, however...
> >
> > In a previous mail thread [1] some 20 months ago, I proposed requiring
> > Java 8 support for some components, particularly the JMS client ahead
> > of its 0.20.0 release, for which the change [2] was made days later
> > given the support voiced.
> >
> > At the time I said I didnt mind proton-j sticking on Java 7 a bit
> > longer, even though most uses of it I was aware of would/did already
> > require 8 at the time. It has now been 'a bit' longer and the switch
> > has never been made, and I'd say its time it was. I'm no longer
> > familiar with any usage of proton-j that doesn't itself require Java 8
> > already. 8 is getting on in years itself now and 11 is almost upon us
> > as the next long lasting version.
> >
> > Thoughts? I'll proceed with the change soon unless there are
> > compelling arguments otherwise.
> >
> > Robbie
> >
> > [1] 
> > https://lists.apache.org/thread.html/00b8f739bd5a653ebb1ce096566fdaf35b0c8cfe749b2ba81bf7c38c@%3Cusers.qpid.apache.org%3E
> > [2] https://issues.apache.org/jira/browse/QPIDJMS-248
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
> -
> 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-J 0.28.1 (RC2)

[Keith W]

(Testing result sent after vote closed.  My vote won't appear in the tally)

+1
* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built and ran tests from source bundle (Java1.8.0_181-b13 Mac OS X 10.11.6)
* Ran Broker-J's JMS client integration test suites against Qpid JMS
Client 0.35.0 overridden with the staged proton artifact Qpid master
build (mvn integration-test -DskipTests -DskipITs=false)
On Fri, 3 Aug 2018 at 12:15, Oleksandr Rudyy  wrote:
>
> +1
>
> * Verified signatures and checksums
> * Built and ran tests from sources with environment variable PN_TRACE_FRM=true
> * Ran successfully Qpid Broker-J integration tests using proton-j
> staged artefacts
>
> On 2 August 2018 at 18:20, Robbie Gemmell  wrote:
> > Hi folks,
> >
> > I have put together a second spin for a Qpid Proton-J 0.28.1 release,
> > please test it and vote accordingly.
> >
> > The files can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.28.1-rc2/
> >
> > The maven artifacts are staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1154
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343744
> >
> > If you are looking at the tag (0.28.1), remember that it has been
> > replaced since RC1, you may need to refresh your checkout.
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test things out using maven with your own build
> > you can temporarily add this to your poms to access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1154
> > 
> >   
> >
> > The dependency for proton-j would then be:
> >
> >   
> > org.apache.qpid
> > proton-j
> > 0.28.1
> >   
> >
> > -
> > 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: [VOTE] Release Apache Qpid Proton-J 0.27.3 (RC2)

[Keith W]

(Testing result sent after vote closed.  My vote won't appear in the tally)

+1
* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built and ran tests from source bundle (Java1.8.0_181-b13 Mac OS X 10.11.6)
* Ran Broker-J's JMS client integration test suites against Qpid JMS
Client 0.35.0 overridden with the staged proton artifact Qpid master
build (mvn integration-test -DskipTests -DskipITs=false)
On Fri, 3 Aug 2018 at 12:16, Oleksandr Rudyy  wrote:
>
> +1
>
> * Verified signatures and checksums
> * Built and ran tests from source bundle with environment variable
> PN_TRACE_FRM=true
> * Ran successfully Qpid Broker-J integration tests using proton-j
> staged artefacts
>
> On 2 August 2018 at 18:19, Robbie Gemmell  wrote:
> > I have put together a second spin for a Qpid Proton-J 0.27.3 release,
> > please test it and vote accordingly.
> >
> > The files can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.27.3-rc2/
> >
> > The maven artifacts are staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1153
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343802
> >
> > If you are looking at the tag (0.27.3), remember that it has been
> > deleted and replaced since RC1, you may need to refresh your checkout.
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test things out using maven with your own build
> > you can temporarily add this to your poms to access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1153
> > 
> >   
> >
> > The dependency for proton-j would then be:
> >
> >   
> > org.apache.qpid
> > proton-j
> > 0.27.3
> >   
> >
> > -
> > 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: [VOTE] Release Apache Qpid Proton-J 0.27.3

[Keith W]

I happened to verify the release in a shell with PN_TRACE_FRM enabled,
this has brought out an NPE from the production code:

https://issues.apache.org/jira/browse/PROTON-1905

On Wed, 1 Aug 2018 at 19:09, Gordon Sim  wrote:
>
> On 31/07/18 16:00, Robbie Gemmell wrote:
> > Hi folks,
> >
> > I have put together a spin for a Qpid Proton-J 0.27.3 release, please
> > test it and vote accordingly.
>
> +1, built from source including successful run of all tests.
>
> -
> 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 JMS AMQP 0-x 6.3.2

[Keith W]

+1

* Verified signatures and checksums
* Check LICENSE and NOTICE files.
* Built and ran tests from source bundle (Java 1.8.0_171-b12, Mac OS X 10.11.6)
* Ran Broker-J's JMS client integration test suites against the staged Qpid JMS
AMQP 0-x Client 6.3.2  (mvn integration-test-DskipTests
-DskipITs=false -P java-mms.0-9
-Dqpid-jms-client-amqp-0-x-version=6.3.2 -DenableAmqp0-x)
On Fri, 13 Jul 2018 at 22:54, Oleksandr Rudyy  wrote:
>
> +1
>
> * verified signatures and checksums
> * built and ran tests from source distribution
> * ran successfully Hello example against Broker-J built from master sources
> * ran Qpid JMS AMQP 0-x integration tests against Broker-J built from
> master sources using maven staged client artefacts
>
>
> On 13 July 2018 at 22:50, Oleksandr Rudyy  wrote:
> > Hi all,
> >
> > I built a candidate release for version 6.3.2 of Qpid JMS AMQP 0-x.
> >
> > Please test and vote accordingly.
> >
> > The source and binary bundles can be taken from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms-amqp-0-x/6.3.2-RC1/
> >
> > The maven artifacts are also staged at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1149
> >
> > The JIRAs currently assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12343485
> >
> > Regards,
> > Alex
> >
> > P.S. If you want to test it out using maven, you can temporarily add this to
> > your project pom to access the staging repo:
> >
> >   
> > 
> >   staging
> >
> > https://repository.apache.org/content/repositories/orgapacheqpid-1149
> > 
> >   
> >
> > The dependency for the client itself would then be:
> >
> >   
> > org.apache.qpid
> > qpid-client
> > 6.3.2
> >   
> >
> > -
> > 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: [VOTE] Release Apache Qpid Proton-J 0.27.2

[Keith W]

+1

* Verified signatures and checksums
* Built and ran tests from source bundle (Java 1.8.0_171-b12, Mac OS X 10.11.6)
* Ran Broker-J's JMS client integration test suites against Qpid JMS
Client 0.34.0 overridden with the staged proton artifact Qpid  master
build (mvn integration-test
-DskipTests -DskipITs=false)
On Fri, 13 Jul 2018 at 21:04, Robbie Gemmell  wrote:
>
> On 13 July 2018 at 20:53, Robbie Gemmell  wrote:
> > On 13 July 2018 at 20:39, Robbie Gemmell  wrote:
> >> Hi folks,
> >>
> >> I have put together a spin for a Qpid Proton-J 0.27.2 release, please
> >> test it and vote accordingly.
> >>
> >> The files can be grabbed from:
> >> https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.27.2-rc1/
> >>
> >> The maven artifacts are staged for now at:
> >> https://repository.apache.org/content/repositories/orgapacheqpid-1147
> >>
> >> The JIRAs assigned are:
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343743
> >>
> >> Regards,
> >> Robbie
> >>
> >> P.S. If you want to test things out using maven with your own build
> >> you can temporarily add this to your poms to access the staging repo:
> >>
> >>   
> >> 
> >>   staging
> >>   
> >> https://repository.apache.org/content/repositories/orgapacheqpid-1147
> >> 
> >>   
> >>
> >> The dependency for proton-j would then be:
> >>
> >>   
> >> org.apache.qpid
> >> proton-j
> >> 0.27.2
> >>   
> >
> > +1
> >
> > I checked things over as follows:
> > - Verified the signature and checksum files.
> > - Checked for LICENCE and NOTICE files in the archives.
> > - Verified the licence headers with mvn apache-rat:check.
> > - Ran the build and tests from source archive.
> > - Used the staged bits with a Qpid JMS master build and ran the tests.
> > - Ran the JMS HelloWorld example against Qpid Broker-J 7.0.6.
> > - Used the staged bits with the ActiveMQ Artemis master build and AMQP 
> > tests.
> > - Used the staged bits with the ActiveMQ 5 master build and AMQP tests.
> >
> > Robbie
>
> Minor correction, it was the Artemis 2.6.x build and tests that I ran,
> not master.
>
> -
> 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-J 0.28.0

[Keith W]

+1

* Verified signatures and checksums
* Checked for LICENCE and NOTICE files in the archives.
* Built and ran tests from source bundle (Java 1.8.0_171-b12, Mac OS X 10.11.6)
* Ran Broker-J's JMS client integration test suites against Qpid JMS
Client 0.34.0 overridden with the staged proton artifact Qpid  master
build (mvn integration-test
-DskipTests -DskipITs=false)
On Fri, 13 Jul 2018 at 21:49, Robbie Gemmell  wrote:
>
> On 13 July 2018 at 21:33, Robbie Gemmell  wrote:
> > Hi folks,
> >
> > I have put together a spin for a Qpid Proton-J 0.28.0 release, please
> > test it and vote accordingly.
> >
> > The files can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.28.0-rc1/
> >
> > The maven artifacts are staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1148
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343104
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test things out using maven with your own build
> > you can temporarily add this to your poms to access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1148
> > 
> >   
> >
> > The dependency for proton-j would then be:
> >
> >   
> > org.apache.qpid
> > proton-j
> > 0.28.0
> >   
>
> +1
>
> I checked things over as follows:
> - Verified the signature and checksum files.
> - Checked for LICENCE and NOTICE files in the archives.
> - Verified the licence headers with mvn apache-rat:check.
> - Ran the build and tests from source archive.
> - Used the staged bits with a Qpid JMS master build and ran the tests.
> - Used the built client in the Qpid Broker-J master build, ran the
> systests using:
>   mvn clean verify -DskipTests=true -DskipITs=false
> - Ran the JMS HelloWorld example against Qpid Broker-J 7.0.6.
> - Used the built client with the ActiveMQ Artemis master (really, this
> time) build and AMQP tests .
> - Used the built client with the ActiveMQ 5 master build and AMQP tests.
>
> 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.24.0

[Keith W]

+1

Built from source bundle, verified checksum and signature and ran unit
tests on Ubuntu 16.04.3 (VM)



On Wed, 27 Jun 2018 at 14:48, Robbie Gemmell 
wrote:
>
> On 27 June 2018 at 13:57, Gordon Sim  wrote:
> > On 26/06/18 18:50, Gordon Sim wrote:
> >>
> >> On 26/06/18 15:56, Robbie Gemmell wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I have put together a spin for a Qpid Proton 0.24.0 release, please
> >>> give it a test out and vote accordingly.
> >>
> >>
> >> +1
> >>
> >> * verified signature and has
> >> * built from source including tests
> >> * built dispatch 1.1.0 against it (some test failures due to
> >> https://issues.apache.org/jira/browse/DISPATCH-1024, fixed on master)
> >> * ran python examples against dispatch
> >> * built qpid-cpp against it
> >
> >
> > I do think it would be worth an explicit release note concerning
> > https://issues.apache.org/jira/browse/PROTON-1354, indicating that
> > applications using GSSAPI which are not explicitly setting that on the
> > client side, will not work as before with this release. The solution is
to
> > have the application clients explicitly set GSSAPI as a/the
sasl-mechanism.
> >
> >
>
> Agreed. I see someone already added a release-notes label to it
> previously and so presumably also agrees.
>
> I think the JIRA should probably contain some text/examples, or links
> to relevant docs, indicating how it is now used.
>
> 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 JMS 0.34.0

[Keith W]

+1

* checked checksums and signatures of the source and bin distribution,
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_171 on Mac OS X 10.11.6)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the staged Maven artefacts
for both the memory and bdb profiles (the latter utilises failover
extensively during HA tests).
On Wed, 27 Jun 2018 at 09:44, Oleksandr Rudyy  wrote:
>
> +1
>
> * verified signatures and checksums
> * verified licence headers using mvn apache-rat:check'
> * built and ran tests from source distribution
> * ran Qpid Broker-J integration tests using staged JMS client 0.34.0 artefacts
>
>
> On 25 June 2018 at 21:11, Robbie Gemmell  wrote:
> > Hi folks,
> >
> > I have put together a spin for a 0.34.0 Qpid JMS client release,
> > please give it a test out and vote accordingly.
> >
> > The source and binary archives can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.34.0-rc1/
> >
> > The maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1146
> >
> > The JIRAs assigned are:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12343438
> >
> > Regards,
> > Robbie
> >
> > P.S. If you want to test it out using maven (e.g with the examples
> > src, or your own things), you can temporarily add this to your poms to
> > access the staging repo:
> >
> >   
> > 
> >   staging
> >   
> > https://repository.apache.org/content/repositories/orgapacheqpid-1146
> > 
> >   
> >
> > The dependency for the client itself would then be:
> >
> >   
> > org.apache.qpid
> > qpid-jms-client
> > 0.34.0
> >   
> >
> > -
> > 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: [Broker-J 7.X] New plugins

[Keith W]

On Tue, 26 Jun 2018 at 12:21, VERMEULEN Olivier
 wrote:
>
> Hello Rob,
>
> Thanks for the information.
> I ended up removing this plugin but for another reason, it doesn't work with 
> Sybase.
> It tries to create the AMQP_1_0_LINKS_VERSION table with a 'TIMESTAMP' column 
> type which is not supported by Sybase.
> And unlike other QPID tables the type cannot be overridden through 
> configuration properties.
>

That would be a defect.  Please raise a JIRA (and include a PR if you wish).

Thanks Keith


> Regards,
> Olivier
>
> -Original Message-
> From: Rob Godfrey 
> Sent: lundi 25 juin 2018 10:17
> To: users@qpid.apache.org
> Subject: Re: [Broker-J 7.X] New plugins
>
> Hi Olivier,
>
> in Qpid Broker-J support was added for storing durable links in AMQP 1.0.
> In order to support this some link state needs to be persisted.  Plugins were 
> added for JDBC and BDB to allow for the link state to be persisted in the 
> same store as message data, however there is also a "Null" link store which 
> should be used if a suitable plugin is not found.  Using this null link store 
> is essentially equivalent to pre-7.0 behaviour; so if you don't need durable 
> links to be stored persistently then should be able to omit the 
> amqp-1-0-jdbc-store plugin.
>
> Hope this helps,
> Rob
>
> On Mon, 25 Jun 2018 at 09:53, VERMEULEN Olivier 
> wrote:
>
> > Hello,
> >
> > While upgrading from Broker-J 6.1.4 to 7.0.3 I realized that there is
> > a new plugin now: amqp-1-0-jdbc-store I can't seem to find any
> > documentation on what this plugin is supposed to do.
> > I'm asking this because I have a problem of table name size with one
> > of the tables coming from this plugin: AMQP_1_0_LINKS_VERSION
> >
> > Thanks,
> > 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.
> >
> ***
>
> 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: [Broker-J 7.0.3] Memory configuration store and messages recovery

[Keith W]

Hello Olivier

Let me say first that the memory store's primary use-case is to aid
development and testing of Broker-J, by speeding ups the test cycle.
It also has utility when using embedding Broker-J in the unit tests of
another project and you want to discard all messaging state between
tests.

You are correct in your analysis.   Queues (like all other objects)
are allocated a random UUID on creation.  This UUID is stored in the
configuration store together with the queue's name and all other
attributes.  Within the message store, the message instance records
refer to the queue's UUID rather than its name.  So if your set-up is
a persistent message store and volatile configuration store, yes, you
will lose messages.  This is expected.  The recovery phase of startup
will clear the message store of the orphans.

What problem are you actually trying to solve?

Keith.



On 22 June 2018 at 08:54, VERMEULEN Olivier  wrote:
> Hello,
>
> I was running some tests on a Java Broker with 'Memory' configuration store 
> and 'DERBY' message store.
> Is there a way with this configuration to recover the messages stored in DB 
> upon a broker restart?
> Because it looks like the messages are mapped to the queue UUID and that they 
> are discarded directly during the broker startup if the queue with the 
> specified UUID is not found.
> And obviously since I'm using a 'Memory' configuration store, the queue has 
> not been recreated yet when the broker starts...
> Have I missed something?
>
> Thanks,
> 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.

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

Re: [VOTE] Release Apache Qpid Broker-J 7.0.6

[Keith W]

+1.

My testing was:

1) Verified the sha512 checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profiles: mms/AMQP1.0 from source bundle (using Qpid
JMS Client 0.33.0)
5) Generally kicked the tyres within the Web Management Console using
Broker from the tar,gz bundle
6) Spun up an embedded Broker-J using the staged maven artefacts.

On 21 June 2018 at 17:50, Gordon Sim  wrote:
> On 19/06/18 22:45, Oleksandr Rudyy wrote:
>>
>> Hi all,
>>
>> I created an RC1 built for a Qpid Broker-J 7.0.6 release.
>> Please give it a test out and vote accordingly.
>
>
> +1, built from source including tests, ran qpid::messaging over both 1.0 and
> 0-10 (including conversion between them), ran python proton examples against
> it.
>
>
> -
> 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 Broker-J 7.0.6

[Keith W]

Alex,

There is a problem with .ascs in the 7.0.6-rc1 tree.  They appear to
contain a literal  html response describing a 404 situation.

svn cat 
https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.0.6-rc1/apache-qpid-broker-j-7.0.6-src.tar.gz.asc
| head -3

  
404 - Repository with ID=orgapacheqpid-1146 not
found





On 19 June 2018 at 22:45, Oleksandr Rudyy  wrote:
> Hi all,
>
> I created an RC1 built for a Qpid Broker-J 7.0.6 release.
> Please give it a test out and vote accordingly.
>
> The source and binary bundles can be found at
> https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.0.6-rc1
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1145
>
> The JIRAs currently assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12343434
>
> Regards,
> Alex
>
> P.S. For testing of maven broker staging repo artefacts, please add into to
> your poms the staging repo as below:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1145
> 
>   
>
>
> -
> 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 Broker-J 7.0.5 RC2

[Keith W]

+1.

My testing was:

1) Verified the md5/sha checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profiles: mms/AMQP1.0, bdb/AMQP0-91, dby/AMQP0-10
from source bundle (using Qpid JMS Client 0.33.0)
5) Generally kicked the tyres within the Web Management Console using
Broker from the tar,gz bundle
6) Spun up an embedded Broker-J using the staged maven artefacts.

On 12 June 2018 at 13:54, Oleksandr Rudyy  wrote:
> +1
>
> I performed the following tests:
> * verified checksums and signature (making sure that md5 checksums are
> not included any more)
> * built broker from sources with running integration tests using
> java-bdb.0-9 profile
> * ran JMS tests publishing large messages exceeding maximum size limits
> * ran JMS tests to verify that consumption speed of large flowed to
> disk messages is back to normal and messages are not reloaded from
> disk every time on sending every content chunk
> * ran JMS tests to verify that virtual host flow to disk thresholds
> are correctly evaluated
>
>
> On 12 June 2018 at 11:49, Oleksandr Rudyy  wrote:
>> Hi all,
>>
>> I created an RC2 built for a Qpid Broker-J 7.0.5 release.
>> Please give it a test out and vote accordingly.
>>
>> The source and binary bundles can be found at
>> https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.0.5-rc2
>>
>> The maven artifacts are also staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1144
>>
>> The JIRAs currently assigned are:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12343398
>>
>> Regards,
>> Alex
>>
>> P.S. For testing of maven broker staging repo artefacts, please add into to
>> your poms the staging repo as below:
>>
>>   
>> 
>>   staging
>>
>> https://repository.apache.org/content/repositories/orgapacheqpid-1144
>> 
>>   
>>
>>
>> -
>> 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: [VOTE] Release Apache Qpid JMS 0.33.0

[Keith W]

+1

* checked checksums and signatures of the source and bin distribution,
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_171 on Mac OS X 10.11.6)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the staged Maven artefacts

On 11 June 2018 at 19:57, Timothy Bish  wrote:
> On 06/11/2018 01:32 PM, Robbie Gemmell wrote:
>>
>> Hi folks,
>>
>> I have put together a spin for a 0.33.0 Qpid JMS client release,
>> please give it a test out and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/jms/0.33.0-rc1/
>>
>> The maven artifacts are also staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1143
>>
>> The JIRAs assigned are:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12343151
>>
>> Regards,
>> Robbie
>>
>> P.S. If you want to test it out using maven (e.g with the examples
>> src, or your own things), you can temporarily add this to your poms to
>> access the staging repo:
>>
>>
>>  
>>staging
>>
>> https://repository.apache.org/content/repositories/orgapacheqpid-1143
>>  
>>
>>
>> The dependency for the client itself would then be:
>>
>>
>>  org.apache.qpid
>>  qpid-jms-client
>>  0.33.0
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
> +1
>
> * Validated signatures and checksums
> * Used mvn apache-rat:check to validate license headers
> * Built from source and ran the tests
> * Built example and ran against a ActiveMQ Artemis broker
> * Built ActiveMQ 5.x and ActiveMQ Artemis using staged bits and ran the
> broker tests.
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
>
> -
> 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 Broker-J 7.0.4

[Keith W]

+1.

My testing was:

1) Verified the md5/sha checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profiles: mms/AMQP1.0, bdb/AMQP0-91, dby/AMQP0-10
from source bundle (using Qpid JMS Client 0.32.0)
5) Generally kicked the tyres within the Web Management Console using
Broker from the tar,gz bundle
6) Spun up an embedded Broker-J using the staged maven artefacts.


On 29 May 2018 at 17:56, Rob Godfrey  wrote:
> +1
>
> - Built from source and ran the tests
> - started the broker from the built source, tested the console, did some ad
> hoc testing with Qpid JMS
>
> -- Rob
>
> On Tue, 29 May 2018 at 17:12, Robbie Gemmell 
> wrote:
>
>> On 28 May 2018 at 14:59, Oleksandr Rudyy  wrote:
>> > Hi all,
>> >
>> > I built a release candidate for a Qpid Broker-J 7.0.4.
>> > Please give it a test out and vote accordingly.
>> >
>> > The source and binary archives can be grabbed from:
>> > https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.0.4-rc1
>> >
>> > The maven artifacts are also staged for now at:
>> > https://repository.apache.org/content/repositories/orgapacheqpid-1141
>> >
>> > The JIRAs currently assigned are:
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12343040
>> >
>> > Regards,
>> > Alex
>> >
>> > P.S. For testing of maven broker staging repo artefacts, please add into
>> to
>> > your poms the staging repo as below:
>> >
>> >   
>> > 
>> >   staging
>> >   
>> > https://repository.apache.org/content/repositories/orgapacheqpid-1141
>> 
>> > 
>> >   
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> > For additional commands, e-mail: users-h...@qpid.apache.org
>>
>> +1
>>
>> I checked things out as follows:
>> - Verified the signature and checksum files.
>> - Checked for LICENCE and NOTICE files being present in each archive.
>> - Used "mvn apache-rat:check" to check headers in the source release.
>> - Ran the source build and all tests from the default profile, using
>> "mvn verify -DskipITs=false".
>> - Started broker from binary convenience archive, used the web console
>> to create a queue, ran the Qpid JMS master HelloWorld example against
>> the broker.
>>
>> 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 JMS AMQP 0-x 6.3.1

[Keith W]

+1

* verified signatures and checksums of the release artefacts
* ran apache rat-check against the source tgz
* built from source distribution artefact and ran all tests (mvn
verify using Java 1.7.0_80 on Mac OS X 10.11.6)
* ran Qpid JMS AMQP 0-x systest suite (on master) against maven staged
client artefact with both Broker-J 7.0.3 for AMQP (0-10/0-91) and CPP
Broker (AMQP 0-10 only)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the Maven staged client
artefact for AMQP (0-10/0-91) .

On 15 May 2018 at 12:36, Oleksandr Rudyy  wrote:
> Hi folks,
>
> I built a candidate release for version 6.3.1 of Qpid JMS AMQP 0-x.
>
> Please test and vote accordingly.
>
> The source and binary bundles can be taken from:
> https://dist.apache.org/repos/dist/dev/qpid/jms-amqp-0-x/6.3.1/
>
> The maven artifacts are also staged at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1140
>
> The JIRAs currently assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12342207
>
> Regards,
> Alex
>
> P.S. If you want to test it out using maven, you can temporarily add this
> to your project pom to access the staging repo:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1140
> 
>   
>
> The dependency for the client itself would then be:
>
>   
> org.apache.qpid
> qpid-client
> 6.3.1
>   
>
> -
> 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: [broker-j 7.0.3] TTL expire to alt binding

[Keith W]

Hi Dan,

No, unfortunately, Broker-J currently does not have that feature.
Currently messages that get TTL'd get unconditionally deleted.

Adding basic support for this feature probably would not be too much
work but is not currently a road-map item.  The queue's model would
need to indicate what TTL behaviour is desired (drop or route to
alternate) and the implementation would need to internally take steps
to avoid TTL delivery loops forming (at least within a single broker
uptime).

I notice that RabbitMQ's adds an "x-death" header [1] to messages
carrying information about why the message is being dead lettered.
I guess this was added to allow an application processing the contents
of a dead letter queue to take appropriate actions. An analogous
feature in Broker-J would present some challenges. Firstly, with the
older AMQP protocols (AMQP 0-8..0-10) the Broker treats the message
headers as immutable (for reasons of spec compliance and performance)
so this would not be a possibility.  In AMQP 1.0 augmenting the
message with an annotation [2] is allowed so I expect this would be a
possibility for this use-case.  However, the Broker's internals would
need considerable refactoring to support this (messages store would
need to be reworked).

cheers
Keith

[1] https://www.rabbitmq.com/dlx.html
[2] 
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-delivery-annotations






On 15 May 2018 at 21:10, Dan Langford  wrote:
> is there way to configure the broker to treat TTL expired messages as other
> "undeliverable" messages by delivering those to the configured Alternate
> Binding?

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

Re: Qpid - How can create JMS Message without using session

[Keith W]

On 10 May 2018 at 22:28, Abhishek Kumar
 wrote:
> Hi Team,
>
> I am using Qpid Java sending and receiving message. For sending any
> message, i need to create JMS message. At this moment, i am creating JMS
> message with the use of session. I want to avoid using session for creating
> message.

What is it that makes you want to avoid using the
Session#createMessage() message factories?  One of Session's many
stated purposes [1] is to be a source of "provider-optimized message
factories". The JMS standard does not define an alternative.  Why try
and work against this?

If you don't want to see the Message objects in your code for some
reason, you could consider the "simplified API" in JMS 2.0 which lets
you send a message by passing only the payload object [2].  Oracle's
example [3] illustrates the differences between the JMS 1.1 and 2.0
API in this respect.  See Listing 2.

[1] https://docs.oracle.com/javaee/7/api/javax/jms/Session.html
[2] 
https://docs.oracle.com/javaee/7/api/javax/jms/JMSProducer.html#send-javax.jms.Destination-java.util.Map-
[3] http://www.oracle.com/technetwork/articles/java/jms20-1947669.html

>
> I know one way to use ActiveMQMessage, but for this i need to use active-mq
> library which i want avoid due adding more dependency.
>
> Could you please suggest any better way to create JMS Message without JMS
> session?
>
>
> Regards,
> Abhishek Kumar

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

Re: [VOTE] Release Apache Qpid JMS 0.32.0

[Keith W]

+1
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvnverify
with Java 1.8.0_162 on Mac OS X 10.11.6)
* ran Broker-J's JMS integration test suite (mvn clean verify
-DskipTests=true -DskipITs=false) against the staged Maven artefacts
* adhoc AMQP 1.0 websocket testing.

I notice QPIDJMS-383 has a typo in its description (coping rather than copying).



On 1 May 2018 at 20:27, Gordon Sim  wrote:
> On 30/04/18 14:12, Robbie Gemmell wrote:
>>
>> I have put together a spin for a 0.32.0 Qpid JMS client release,
>> please give it a test out and vote accordingly.
>
>
> +1, built from source and ran against router
>
>
> -
> 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-J 0.27.1

[Keith W]

+1

* Built and ran tests from source bundle (Java 1.8.0_162-b12, Mac OS X 10.11.6)
* Ran Broker-J's JMS client integration test suites against staged
artefacts with a Qpid JMS master build (mvn integration-test
-DskipTests -DskipITs=false)


On 26 April 2018 at 12:34, Robbie Gemmell  wrote:
> On 25 April 2018 at 21:50, Robbie Gemmell  wrote:
>> I have put together a spin for a Qpid Proton-J 0.27.1 release, please
>> test it and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.27.1-rc1/
>>
>> The maven artifacts are staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1138
>>
>> The only change is https://issues.apache.org/jira/browse/PROTON-1836, which
>> affects use of some new functionality added in 0.27.0.
>>
>> Regards,
>> Robbie
>>
>> P.S. If you want to test things out using maven with your own build
>> you can temporarily add this to your poms to access the staging repo:
>>
>>   
>> 
>>   staging
>>   
>> https://repository.apache.org/content/repositories/orgapacheqpid-1138
>> 
>>   
>>
>> The dependency for proton-j would then be:
>>
>>   
>> org.apache.qpid
>> proton-j
>> 0.27.1
>>   
>
> +1
>
> I checked things over as follows:
> - Verified the signature and checksum files.
> - Checked for LICENCE and NOTICE files in the archives.
> - Verified the source archive licence headers with mvn apache-rat:check.
> - Ran the build and tests from source archive.
> - Used the staged bits with a Qpid JMS master build and ran the tests.
> - Used built client in the Qpid Broker-J master build and tests.
> - Used the client and Qpid Broker-J master to run the joram tests.
> - Used the staging repo and built client with the ActiveMQ Artemis master
>   build and AMQP tests.
> - Ran the JMS HelloWorld example against Broker-J, Dispatch, and
> Artemis masters.
>
>
> 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-J 0.27.0 (RC2)

[Keith W]

+1

* Built and ran tests from source bundle (Java 1.8.0_162-b12, Mac OS X 10.11.6)
* Ran Broker-J's JMS client integrations test suites against staged
artefacts (mvn integration-test -DskipTests -DskipITs=false)
* Performed an adhoc JMS client test similar to that that allowed by
to raise PROTON-1672.
* Confirmed that issue reported against RC1 had indeed gone.

On 19 April 2018 at 11:15, Robbie Gemmell  wrote:
> On 18 April 2018 at 21:01, Robbie Gemmell  wrote:
>> Hi folks,
>>
>> I have put together a second spin for a Qpid Proton-J 0.27.0 release, please
>> test it and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.27.0-rc2/
>>
>> The maven artifacts are staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1137
>>
>> The JIRAs assigned are:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12342819
>>
>> Regards,
>> Robbie
>>
>> P.S. If you want to test things out using maven with your own build
>> you can temporarily add this to your poms to access the staging repo:
>>
>>   
>> 
>>   staging
>>   
>> https://repository.apache.org/content/repositories/orgapacheqpid-1137
>> 
>>   
>>
>> The dependency for proton-j would then be:
>>
>>   
>> org.apache.qpid
>> proton-j
>> 0.27.0
>>   
>
> +1
>
> I checked things over as follows:
> - Verified the signature and checksum files.
> - Checked for LICENCE and NOTICE files in the archives.
> - Verified the source archive licence headers with mvn apache-rat:check.
> - Ran the build and tests from source archive.
> - Used the staged bits with a Qpid JMS master build and ran the tests.
> - Used built client in the Qpid Broker-J master build and [sys]tests.
> - Used the client and Qpid Broker-J master to run the joram tests.
> - Ran some manual tests with PN_TRACE_FRM enabled to verify RC1 issue fixed.
> - Used the staging repo and built client with the ActiveMQ Artemis master
>   build and AMQP tests.
> - Ran the JMS HelloWorld example against Broker-J, Dispatch, and
> Artemis masters.
>
> 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-J 0.27.0

[Keith W]

With the 0.27.0 RC (and the Qpid JMS Client 0.31.0) I am noticing a
java.lang.ArrayIndexOutOfBoundsException when PN_TRACE_FRM=true, which
did not occur with 0.26.0.

My JMS code fragment (based on HelloWorld).

Context context = new InitialContext();
ConnectionFactory factory = (ConnectionFactory)
context.lookup("myFactoryLookup");
Destination queue = (Destination) context.lookup("myQueueLookup");
Connection connection =
factory.createConnection(System.getProperty("USER"),
System.getProperty("PASSWORD"));
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer messageProducer = session.createProducer(queue);
BytesMessage message = session.createBytesMessage();
message.writeBytes(new byte[261955 /*261954 wont produce the AIOOBE*/]);
messageProducer.send(message);

and the protocol trace/stack trace:

/Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/bin/java
-DUSER=admin -DPASSWORD=admin "-javaagent:/Applications/IntelliJ
IDEA.app/Contents/lib/idea_rt.jar=53139:/Applications/IntelliJ
IDEA.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath

Re: Broker-J BDB JE High Availability Time Sync issue

[Keith W]

Hi Bryan

I haven't seen problem reports raised against Broker-J regarding this error.

The error actually originates from the HA feature within Berkeley BDB JE.
There's a useful reply within the following thread that explains some
background about how the maximum clock delta is used.

https://community.oracle.com/thread/1027853

For this problem to appear,  I see three possibilities:

1) The NTP synchronisation between the nodes was somehow ineffective
causing a genuine skew between the nodes
2) The processing BDB JE internal
com.sleepycat.je.rep.stream.Protocol.SNTPResponse was somehow delayed
causing a spurious exception to be reported on the master.  I am wondering
whether an unfortunately timed lengthy GC pause could cause this.
3) There is some kind of previously unknown defect in BDB JE HA itself.

To help you narrow in, I'd suggest changing the logging configuration so
you retain logs for longer so if you see a reoccurrence you have more to
investigate.   I also suggest turning GC logging with timestamps, at the
JVM level.

You could also consider raising je.rep.maxClockDelta.  Broker-J doesn’t
actually change the replica consistency policy settings from their
defaults, which includes the permitted clock delta setting.  A BDB HA node
never actually reads from the replicated environment until the node becomes
master.  This means the concerns described by
https://docs.oracle.com/cd/E17277_02/html/ReplicationGuide/consistency.html
don't actually apply.   (As an aside I note that
 NoConsistencyRequiredPolicy (rather the TimeConsistencyPolicy default)
should serve Broker-J's use case just as well - but this is not something I
have tried or investigated completely).

Hope this helps.

Keith Wall.


On Mon, 16 Apr 2018 at 18:54, Bryan Dixon  wrote:

> We are using Broker-J 7.0.2 and just ran into a Berkeley HA Time Sync issue
> that I'm wondering if anyone else has run into.  The stackTrace is at the
> end of this post.   We are running on Windows Server 2012 R2 6.3 amd64 and
> our JDK is Oracle Corporation 1.8.0_162-b12.  We have 3 servers as part of
> our HA setup.
>
> This error occurred in our production environment which has been live for
> just a couple of weeks.  We never ran into this in our Test or Dev
> environments that have been running for a few months.   When one of our
> admins checked the clock times of all 3 servers they were completely in
> sync.  Another admin stated that the server clock times are synced with
> NTP.
> Unfortunately our log files rolled off and I don't know exactly when this
> error first occurred because the older log file are gone.
>
> 2018-04-16 04:10:57,039 ERROR [Group-Change-Learner:prodbrok
> er:prodbroker2]
> (o.a.q.s.u.ServerScopedRuntimeException) - Exception on master check
> com.sleepycat.je.EnvironmentFailureException: (JE 7.4.5) Environment must
> be
> closed, caused by: com.sleepycat.je.EnvironmentFailureException:
> Environment
> invalid because of previous exception: (JE 7.4.5)
> prodbroker2(2):D:\qpidwork\prodbroker2\config Clock delta: 8859 ms.
> between
> Feeder: prodbroker1 and this Replica exceeds max permissible delta: 2000
> ms.
> HANDSHAKE_ERROR: Error during the handshake between two nodes. Some
> validity
> or compatibility check failed, preventing further communication between the
> nodes. Environment is invalid and must be closed. Originally thrown by HA
> thread: UNKNOWN prodbroker2(2) Originally thrown by HA thread: UNKNOWN
> prodbroker2(2)
> at
> com.sleepycat.je.EnvironmentFailureException.wrapSelf(Enviro
> nmentFailureException.java:228)
> at
> com.sleepycat.je.dbi.EnvironmentImpl.checkIfInvalid(Environm
> entImpl.java:1766)
> at
> com.sleepycat.je.dbi.EnvironmentImpl.checkOpen(EnvironmentImpl.java:1775)
> at com.sleepycat.je.Environment.checkOpen(Environment.java:2473)
> at com.sleepycat.je.DbInternal.checkOpen(DbInternal.java:105)
> at
> com.sleepycat.je.rep.ReplicatedEnvironment.checkOpen(Replica
> tedEnvironment.java:1052)
> at
> com.sleepycat.je.rep.ReplicatedEnvironment.getState(Replicat
> edEnvironment.java:764)
> at
> org.apache.qpid.server.store.berkeleydb.replication.Replicat
> edEnvironmentFacade$RemoteNodeStateLearner.executeDatabasePi
> ngerOnNodeChangesIfMaster(ReplicatedEnvironmentFacade.java:2276)
> at
> org.apache.qpid.server.store.berkeleydb.replication.Replicat
> edEnvironmentFacade$RemoteNodeStateLearner.call(ReplicatedEn
> vironmentFacade.java:2042)
> at
> org.apache.qpid.server.store.berkeleydb.replication.Replicat
> edEnvironmentFacade$RemoteNodeStateLearner.call(ReplicatedEn
> vironmentFacade.java:2012)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
> 

Re: [Java Broker] Temporary queues ACLs for multiple users

[Keith W]

Hi Tomas

Having had change to reflect on this a bit more, I am contemplating a
change to the existing access-control-plugin which would let you
express rules for objects that the current user has created using a
special pseudo subject 'OWNER'.

It will look something like:

ACL ALLOW-LOG OWNER CONSUME QUEUE

This rule would allow anyone who was the creator of queue (as carried
by the queue's createdBy attribute), to consume from it.

If such an extension existed, would it solve your use-case?  I hope to
have a patch up for you to play with tomorrow.

cheers, Keith.



On 6 April 2018 at 11:25, Vavricka  wrote:
> Hi Keith,
>
> thanks for explanation.
>
> It will be great if you can post skeletal code of ACL module.
>
> Tomas
>
>
> Keith Wall wrote
>> Hi Tomas
>>
>> Unfortunately, Broker-J's access_control plugin is not too good.  It
>> is something we would like to rework when schedules allow.  The
>> current module actually uses an object modal that pre-dates the
>> current one - which leads to user confusion and an ugly adaption layer
>> in the code.  The ACL also assumes AMQP 0-x conventions - publishing
>> only to exchanges and consuming from queues when expressing rules
>> which creates a further wrinkle when using AMQP 1.0.
>>
>> The current module lets you specify rules that match objects using
>> zero or more property qualifiers (e.g. name="foo" or type="fanout"),
>> so it is possible to write rules about named objects in your system
>> and all objects matching certain criteria.   For temporary queues,
>> this doesn't work well as you have discovered.  It is possible to say
>> that user foo can (or cannot) consume from any temporary queue using
>> the temporary=true qualifier, but it is not possible to be specific,
>> but you cannot express a rule that gives users to temporary queues
>> that they have created.
>>
>> The ACL mechanism is pluggable - so it would be possible to write a
>> module that would give the behaviour you need.  You would need to look
>> at the AccessControlProvider and AccessControl interfaces.  The Broker
>> supports one or more access control providers.  It consults each
>> AccessControlProvider in order until one make a decision that is not
>> DEFER.  So you could hopefully write a simple ACL module that you give
>> you the additional behaviour you need and fallback on access_control
>> plugin for everything else.  If you want to explore this route, I
>> could share some skeletal code to help get you started.
>>
>> Turning to your last point, when using AMQP 1.0 and wishing to
>> permission publishing directly to queues, as access_control plugin
>> knows only AMQP 0-x conventions you have to permission the default
>> exchange.
>>
>> ACL ALLOW-LOG foo PUBLISH EXCHANGE name="" routingKey="queueName"
>>
>> Hope this helps.
>>
>> Keith
>>
>> On 5 April 2018 at 14:46, Vavricka 
>
>> vavricka.tomas@
>
>>  wrote:
>>> Hi,
>>>
>>> I am trying to get working temporary queues on Java Broker. Each user
>>> should
>>> have access only to queue which he created.
>>>
>>> ACL rights:
>>>
>>> ACL ALLOW-LOG user1 ACCESS VIRTUALHOST
>>> ACL ALLOW-LOG user1 CREATE QUEUE temporary="true" owner="user1"
>>> ACL ALLOW-LOG user1 CONSUME QUEUE temporary="true" owner="user1"
>>>
>>> ACL ALLOW-LOG user2 ACCESS VIRTUALHOST
>>> ACL ALLOW-LOG user2 CREATE QUEUE temporary="true" owner="user2"
>>> ACL ALLOW-LOG user2 CONSUME QUEUE temporary="true" owner="user2"
>>>
>>> I successfully create temporary queue by JMS method "TemporaryQueue
>>> temporaryQueue = session.createTemporaryQueue()", queue is correctly
>>> created
>>> on broker, but owner is not set in webgui (however createdBy and
>>> lastUpdatedBy in JSON is correctly set to corresponding user).
>>>
>>> When I try to create consumer by "MessageConsumer consumer =
>>> session.createConsumer(temporaryQueue)", I get "Permission CREATE is
>>> denied
>>> for : Consumer ...". When owner is not set in CONSUME ACL I can create
>>> consumer without error, but both users can consume same queue. Is there
>>> any
>>> different way to distinguish temporary queues, so one user cannot read
>>> other
>>> user messages?
>>>
>>> Another issue is I cannot sent messages directly to temporary queue. When
>>> I
>>> try to send message I get error "Permission PERFORM_ACTION(publish) is
>>> denied for : Queue 'TempQueueba2f889e-f95c-49d4-8c15-023e62666320'". We
>>> could utilize sending messages directly to queue, because we cannot
>>> dynamically create exchange binding by REST API. Or is there any way to
>>> set
>>> bindings by JMS?
>>>
>>> Java Broker 7.0.3
>>> Qpid JMS client 0.31.0
>>>
>>> Tomas
>>>
>>>
>>>
>>> --
>>> Sent from:
>>> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>>>
>>> -
>>> To unsubscribe, e-mail:
>
>> users-unsubscribe@.apache
>
>>> For additional commands, e-mail:
>
>> users-help@.apache
>
>>>
>>
>> 

Re: [Java Broker] Temporary queues ACLs for multiple users

[Keith W]

Hi Tomas

Unfortunately, Broker-J's access_control plugin is not too good.  It
is something we would like to rework when schedules allow.  The
current module actually uses an object modal that pre-dates the
current one - which leads to user confusion and an ugly adaption layer
in the code.  The ACL also assumes AMQP 0-x conventions - publishing
only to exchanges and consuming from queues when expressing rules
which creates a further wrinkle when using AMQP 1.0.

The current module lets you specify rules that match objects using
zero or more property qualifiers (e.g. name="foo" or type="fanout"),
so it is possible to write rules about named objects in your system
and all objects matching certain criteria.   For temporary queues,
this doesn't work well as you have discovered.  It is possible to say
that user foo can (or cannot) consume from any temporary queue using
the temporary=true qualifier, but it is not possible to be specific,
but you cannot express a rule that gives users to temporary queues
that they have created.

The ACL mechanism is pluggable - so it would be possible to write a
module that would give the behaviour you need.  You would need to look
at the AccessControlProvider and AccessControl interfaces.  The Broker
supports one or more access control providers.  It consults each
AccessControlProvider in order until one make a decision that is not
DEFER.  So you could hopefully write a simple ACL module that you give
you the additional behaviour you need and fallback on access_control
plugin for everything else.  If you want to explore this route, I
could share some skeletal code to help get you started.

Turning to your last point, when using AMQP 1.0 and wishing to
permission publishing directly to queues, as access_control plugin
knows only AMQP 0-x conventions you have to permission the default
exchange.

ACL ALLOW-LOG foo PUBLISH EXCHANGE name="" routingKey="queueName"

Hope this helps.

Keith

On 5 April 2018 at 14:46, Vavricka  wrote:
> Hi,
>
> I am trying to get working temporary queues on Java Broker. Each user should
> have access only to queue which he created.
>
> ACL rights:
>
> ACL ALLOW-LOG user1 ACCESS VIRTUALHOST
> ACL ALLOW-LOG user1 CREATE QUEUE temporary="true" owner="user1"
> ACL ALLOW-LOG user1 CONSUME QUEUE temporary="true" owner="user1"
>
> ACL ALLOW-LOG user2 ACCESS VIRTUALHOST
> ACL ALLOW-LOG user2 CREATE QUEUE temporary="true" owner="user2"
> ACL ALLOW-LOG user2 CONSUME QUEUE temporary="true" owner="user2"
>
> I successfully create temporary queue by JMS method "TemporaryQueue
> temporaryQueue = session.createTemporaryQueue()", queue is correctly created
> on broker, but owner is not set in webgui (however createdBy and
> lastUpdatedBy in JSON is correctly set to corresponding user).
>
> When I try to create consumer by "MessageConsumer consumer =
> session.createConsumer(temporaryQueue)", I get "Permission CREATE is denied
> for : Consumer ...". When owner is not set in CONSUME ACL I can create
> consumer without error, but both users can consume same queue. Is there any
> different way to distinguish temporary queues, so one user cannot read other
> user messages?
>
> Another issue is I cannot sent messages directly to temporary queue. When I
> try to send message I get error "Permission PERFORM_ACTION(publish) is
> denied for : Queue 'TempQueueba2f889e-f95c-49d4-8c15-023e62666320'". We
> could utilize sending messages directly to queue, because we cannot
> dynamically create exchange binding by REST API. Or is there any way to set
> bindings by JMS?
>
> Java Broker 7.0.3
> Qpid JMS client 0.31.0
>
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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 Qpid for Java 6.1.6

[Keith W]

+1.

My testing was:

1) Verified the sha512 checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profile bdb (0-9) and dby (0-10) from source bundle
5) Ran hello world against staged maven client artefacts against
broker from binary distribution artefact
6) Repeated a manual test verifying the fix for QPID-8144 (Memory
compaction may not run when Direct Memory exceeds 2GB)

On 2 April 2018 at 13:24, Robbie Gemmell  wrote:
> On 30 March 2018 at 16:45, Oleksandr Rudyy  wrote:
>> Hi all,
>>
>> A bug-fix release candidate for the version 6.1.6 of the Qpid for
>> Java Components has been created.
>>
>> The list of defect fixes can be found in Jira:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12342163
>>
>> Please test and vote accordingly.
>>
>> The source and binary archives can be grabbed from here:
>> https://dist.apache.org/repos/dist/dev/qpid/java/6.1.6-rc1
>>
>> Those files and the other maven artifacts are also staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1135
>>
>> Kind regards
>>
>> P.S. If you want to test it out using maven (e.g with the examples src,
>> or your own things), you can temporarily add this to your poms to access
>> the staging repo:
>>
>>   
>> 
>>   staging
>>   
>> https://repository.apache.org/content/repositories/orgapacheqpid-1135
>> 
>>   
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>
> +1
>
> I checked things over as follows:
> - Verified the signature and checksum files.
> - Used "mvn apache-rat:check" to verify the headers in source release.
> - Checked for LICENCE and NOTICE files being present in each archive.
> - Ran the source build and tests using the default profile, all passed.
> - Started the broker, used the web console to create a queue, ran the
> Qpid JMS master HelloWorld example against the broker.
>
> 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: Building proton from master fails on Red Hat Enterprise Linux Server release 7.3 Maipo with "fatal error: bits/c++config.h: No such file or directory"

[Keith W]

On 3 April 2018 at 10:31, Robbie Gemmell  wrote:
> "The package is not listed as required in INSTALL.md, I am curious
> whether the instructions needs to be amended to include this package."
>
> It seems its a dependency of the "gcc-c++" package which is mentioned,
> so I'd guess thats why it isnt noted explicitly. Not sure how you came
> to have the x64 version of one and the i686 version of the other
> though.
>

Thanks for the replies.  The 7.3 Maipo image in question is
corporatised by our organisation, so it could be special in this
respect.

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

Re: [VOTE] Release Apache Qpid Broker-J 7.0.3

[Keith W]

+1.

My testing was:

1) Verified the md5/sha checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profile mms/bdb 0-9/0-10//1.0 from source bundle
(Qpid JMS Client 0.31.0)
5) Generally kicked the tyres within the Web Management Console using
Broker from the tar,gz bundle
6) Spun up an embedded Broker-J using the staged maven artefacts.
7) Repeated a manual test verifying the fix for QPID-8144 (Memory
compaction may not run when Direct Memory exceeds 2GB)

On 2 April 2018 at 12:47, Robbie Gemmell  wrote:
> On 30 March 2018 at 15:40, Oleksandr Rudyy  wrote:
>> Hi all,
>>
>> I built a release candidate for a Qpid Broker-J 7.0.3.
>> Please give it a test out and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.0.3-rc1
>>
>> The maven artifacts are also staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1134
>>
>> The JIRAs currently assigned are:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12342887
>>
>> Regards,
>> Alex
>>
>> P.S. For testing of maven broker staging repo artefacts, please add into to
>> your poms the staging repo as below:
>>
>>   
>> 
>>   staging
>>   
>> https://repository.apache.org/content/repositories/orgapacheqpid-1134
>> 
>>   
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>
> +1
>
> I checked things over as follows:
> - Verified the signature and checksum files.
> - Used "mvn apache-rat:check" to verify the headers in source release.
> - Checked for LICENCE and NOTICE files being present in each archive.
> - Ran the source build and tests using the default profile, all good.
> - Started the broker, used the web console to create a queue, ran the
> Qpid JMS master HelloWorld example against the broker.
>
> 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 STOMP support

[Keith W]

Deven,

Speaking for Apache Qpid Broker-J only, there are no plans to add STOMP support.

Keith.

On 26 March 2018 at 09:39, deven parab  wrote:
> Hi Team,
> Just wanted to check with you whether QPid has STOMP support 
> and if it does what is the port no. and if it doesn't when are you guys 
> planning to?
>
> Thanks in advance!
>
> Sent from Yahoo Mail on Android

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

Re: [VOTE] Release Apache Qpid JMS 0.31.0

[Keith W]

+1

* Validated signatures and checksums
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_162 on Mac OS X 10.11.6)
* ran Broker-J's JMS test suite (qpid-systests-jms_2.0 &
qpid-systests-jms_1.1 - master) against the staged Maven artefacts

However, I ran into a problem testing QPIDJMS-367 with Google OAuth
and Broker-J.

Google's access_tokens from /oauth2/v4/token use characters drawn from
outside Base64's 64 character set.   RFC 6749[1] defines an
access_token element as within %x20-7E, so the code within
org.apache.qpid.jms.sasl.XOauth2Mechanism#isApplicable is too
restrictive.  On temporarily hacking out the restriction,
authentication worked correctly.  This is something that should be
fixed, but is not so critical to me not to +1 this release. Thoughts?

[1] https://tools.ietf.org/html/rfc6749#page-73


On 23 March 2018 at 13:02, Oleksandr Rudyy  wrote:
> +1
>
> * Validated signatures and checksums
> * Built from source and ran the tests
> * Ran Broker-J master system tests against staged artefacts using
> profiles java-mms.1-0 and java-bdb.1-0
> * Built sample application publishing messages into Broker-J
> 7.0.3-SNAPSHOT using staged artefacts
>
>
> On 22 March 2018 at 18:44, Robbie Gemmell  wrote:
>> Hi folks,
>>
>> I have put together a spin for a 0.31.0 Qpid JMS client release,
>> please give it a test out and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/jms/0.31.0-rc1/
>>
>> The maven artifacts are also staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1133
>>
>> The JIRAs assigned are:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12342832
>>
>> Regards,
>> Robbie
>>
>> P.S. If you want to test it out using maven (e.g with the examples
>> src, or your own things), you can temporarily add this to your poms to
>> access the staging repo:
>>
>>   
>> 
>>   staging
>>   
>> https://repository.apache.org/content/repositories/orgapacheqpid-1133
>> 
>>   
>>
>> The dependency for the client itself would then be:
>>
>>   
>> org.apache.qpid
>> qpid-jms-client
>> 0.31.0
>>   
>>
>> -
>> 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: JMSMessageID differences in JMS 0.30.0 and JMS AMQP 0-x 6.3.0 clients

[Keith W]

Thanks Bryan - that's clear now.  We'll take a look.

On 22 March 2018 at 19:11, Bryan Dixon  wrote:
> I have an example attached.   The PublishMessage code needs to use the JMS
> 0.30.0 client.  The BrowseMessage code needs to use the MS AMQP 0-x 6.3.0
> client.  When you run the BrowseMessage after publishing the message you'll
> see where it can't find the message by the JMSMessageID it is returning.
>
> What's more interesting is in the BrowseMessage if you uncomment this code:
> System.setProperty("qpid.amqp.version", "0-8");
>
> it works successfully.  And the JMSMessageID is what I get when I get the
> message id from a JMS 0.30.0 client.
>
>
> PublishMessage.java
> 
> BrowseMessage.java
> 
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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: JMSMessageID differences in JMS 0.30.0 and JMS AMQP 0-x 6.3.0 clients

[Keith W]

On 22 March 2018 at 18:59, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> I'd guess that the brokers message conversion is taking the sent AMQP
> 1.0 message, finding it has a string message-id, and processing it
> such that it ends up with a UUID in the converted AMQP 0-10 message
> metadata. That in itself isnt an issue, but if thats happening the
> broker would also need to ensure 0-10 consumers had processed the ID
> similarly when any selection is being performed for them.
>

Possible.  I wasn't completely certain from Bryan's description if it
was relying of the Broker's message conversion feature.   Some
producer and consumer code would take the guess work away.

> Robbie
>
> On 22 March 2018 at 18:48, Keith W <keith.w...@gmail.com> wrote:
>> Bryan,
>>
>> That seems surprising. I am not aware of any such problem.  Do you
>> have an executable example that demonstrates the problem?
>>
>> cheers, Keith.
>>
>> On 22 March 2018 at 17:55, Bryan Dixon <br...@bldixon.net> wrote:
>>> We are using Qpid JMS 0.30.0 to publish messages to a Broker-J 7.0.2 broker.
>>> We have some java apps that have to use the older JMS AMQP 0-x 6.3.0 client
>>> and others that can use the newer JMS 0.30.0 client.  I just found that when
>>> using the JMS Message.getJMSMessageID() method call for the same message
>>> results in 2 different messages Ids being returned by each client version.
>>> That by itself I guess is OK but not what I would expect.  The bigger issue
>>> I just noticed with the older JMS AMQP 0-x 6.3.0 client is when I get the
>>> JMSMessageID value, I can't use that value returned in a message selector to
>>> retrieve (either consume or browse) that message - the message is not found.
>>>
>>> Here is an example.  I published a message and the JMS JMS 0.30.0 client
>>> returns the following value from the Message.getJMSMessageID()  call:
>>> ID:eventapp-40500566-2ca4-439e-9a2d-4e00c88ea682:9:1:1-1
>>>
>>> However when using the JMS AMQP 0-x 6.3.0 client Message.getJMSMessageID()
>>> call on the same exact message call the following ID is returned:
>>> ID:fcae0a4b-9810-3214-b161-8572e5df8ea6
>>>
>>> When I use the QueueBrowser class with the JMS AMQP 0-x 6.3.0 client to
>>> browse the message using this message selector the message is not returned
>>> by the browse() method:
>>> JMSMessageID ='ID:fcae0a4b-9810-3214-b161-8572e5df8ea6'
>>>
>>> It doesn't seem right that the 6.3.0 client can't retrieve the message by
>>> the JMSMessageID it returned.
>>>
>>> I need a way to be able to retrieve a message by its ID for the  6.3.0
>>> client.  This does work successfully wit the JMS 0.30.0 client.
>>>
>>> Bryan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>>>
>>> -
>>> 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
>

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

Re: JMSMessageID differences in JMS 0.30.0 and JMS AMQP 0-x 6.3.0 clients

[Keith W]

Bryan,

That seems surprising. I am not aware of any such problem.  Do you
have an executable example that demonstrates the problem?

cheers, Keith.

On 22 March 2018 at 17:55, Bryan Dixon  wrote:
> We are using Qpid JMS 0.30.0 to publish messages to a Broker-J 7.0.2 broker.
> We have some java apps that have to use the older JMS AMQP 0-x 6.3.0 client
> and others that can use the newer JMS 0.30.0 client.  I just found that when
> using the JMS Message.getJMSMessageID() method call for the same message
> results in 2 different messages Ids being returned by each client version.
> That by itself I guess is OK but not what I would expect.  The bigger issue
> I just noticed with the older JMS AMQP 0-x 6.3.0 client is when I get the
> JMSMessageID value, I can't use that value returned in a message selector to
> retrieve (either consume or browse) that message - the message is not found.
>
> Here is an example.  I published a message and the JMS JMS 0.30.0 client
> returns the following value from the Message.getJMSMessageID()  call:
> ID:eventapp-40500566-2ca4-439e-9a2d-4e00c88ea682:9:1:1-1
>
> However when using the JMS AMQP 0-x 6.3.0 client Message.getJMSMessageID()
> call on the same exact message call the following ID is returned:
> ID:fcae0a4b-9810-3214-b161-8572e5df8ea6
>
> When I use the QueueBrowser class with the JMS AMQP 0-x 6.3.0 client to
> browse the message using this message selector the message is not returned
> by the browse() method:
> JMSMessageID ='ID:fcae0a4b-9810-3214-b161-8572e5df8ea6'
>
> It doesn't seem right that the 6.3.0 client can't retrieve the message by
> the JMSMessageID it returned.
>
> I need a way to be able to retrieve a message by its ID for the  6.3.0
> client.  This does work successfully wit the JMS 0.30.0 client.
>
> Bryan
>
>
>
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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: What is AMQP 1-0 spec complaint Broker behaviour for deletion of queue with consumers attached?

[Keith W]

On 22 March 2018 at 14:46, Gordon Sim  wrote:
> On 22/03/18 14:02, Rob Godfrey wrote:
>>
>> Another consistent model is to say that a queue cannot be deleted while
>> there are associated sending or receiving links.
>
>
> The c++ broker does refuse to delete in use queues by default, but it has a
> a 'force' flag that will override this if desired.
>

what does 'in use' mean?  does it mean there are no are associated
sending or receiving links, or does it mean that there are no open
transactions that affect the contents of the queue?
If the former, I see a problem.  The anonymous terminus (or a Qpid
Exchange) can be used to route messages to a queue without a AMQP 1.0
link being established to it.  This means there could be transactional
work on a queue and the queue would still pass the 'not-in-use' test.

> I'm coming round to Alan's view (which is handy as that requires no change
> to the c++ broker :-).
>
>
> -
> 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: What is AMQP 1-0 spec complaint Broker behaviour for deletion of queue with consumers attached?

[Keith W]

I do appreciate the logic in Allan's suggestion, but it still feels
weird the transaction would apparently succeed even though the
messages were lost.  I like the idea of marking the transaction
'rollback only'.  I agree that if the transaction coordinator actually
rolls-back, the roll-back should proceed without failure.

On 22 March 2018 at 12:11, Robbie Gemmell  wrote:
> While I lean toward failing the transaction if an attempt to commit
> was made, when I started reading the thread just now I did also think
> of essentially the same as below before I got to Alans mails. At the
> end of the day whether the transaction succeeds or fails the end
> result to the users is actually still about the same, the messages in
> question no longer exist since the queue no longer exists. However I
> do think its better to fail a commit attempt since we never actually
> got to make the changes on there because it went away.
>
> On 21 March 2018 at 13:46, Alan Conway  wrote:
>> On Tue, Mar 20, 2018 at 9:07 AM, Oleksandr Rudyy  wrote:
>>
>>> I think that publishing/consuming transactions should not be
>>> committable after queue deletion.
>>>
>>
>> To play devils advocate: the transaction is isolated (the I in ACID)  and
>> queue deletion is outside the scope of the transaction.
>> Consider these sequences:
>>
>> tx-start, send message, tx-end, queue deleted
>> tx-start, send message, queue deleted, tx-end
>>
>> The observable state of the system is identical after both, and since
>> deleting the queue is not part of the transaction, the ordering of the
>> queue deletion with respect to the transaction boundaries is irrelevant and
>> the transaction should succeed in both cases. The transaction only
>> guarantees that the message reach the queue (atomically with other
>> transactional activity), it guarantees nothing about the life-span of the
>> queue with respect to the life-span of the transaction.
>>
>>
>>
>>> As a developer of messaging solution I would find it odd to be able to
>>> commit transaction successfully after queue deletion (even when all my
>>> messages settled and reached terminal state).
>>> Though, I would expect to complete rollback successfully in this case.
>>>
>>> I think that such behaviour would be least surprising for the end users.
>>>
>>> Though, I am not sure what behaviour should be when messages are
>>> published via exchange and routed into deleted queue
>>>
>>>
>>>
>>>
>>> On 20 March 2018 at 11:37, Rob Godfrey  wrote:
>>> > On 20 March 2018 at 12:30, Gordon Sim  wrote:
>>> >
>>> >> On 20/03/18 11:13, Oleksandr Rudyy wrote:
>>> >>
>>> >>> I think than on queue deletion the Broker should do the following for
>>> >>> AMQP 1.0 endpoints
>>> >>>   * send DETACH performative with an error "amqp:resource-deleted" to
>>> >>> all attached links
>>> >>>   * delete all information about detached links
>>> >>>
>>> >>
>>> >> That is what the c++ broker does.
>>> >>
>>> >>
>>> >>
>>> > How do we treat transactions which have transactionally enqueued a
>>> message
>>> > on the (now deleted) queue - do we allow them to commit successfully, or
>>> do
>>> > we force a rollback?  Similarly when a message has been sent from the
>>> queue
>>> > and accepted as part of a transaction?
>>> >
>>> > -- Rob
>>> >
>>> >
>>> >> -
>>> >> 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
>

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

Re: Broker-J Queue Message persistent override

[Keith W]

Hi Bryan

You are modifying the correct attribute on the queue.   At the API
level it is called Queue#messageDurability.  Within the Queue UI it is
labelled "Persist Messages". There is no good reason for the
inconsistency in terminology here. My apologies for any confusion.

>From your description on the behaviour, the feature is working
correctly.   The feature tells the queue to override the sender's
message persistence wishes: ALWAYS will cause the queue to consider
the message to be handled as if it were persistent, NEVER as if it
were not persistent.  DEFAULT respects the sender's original
persistence wish.  The feature influences the queue's storage
behaviour. It does not cause the message's header to be rewritten.
The message's header conveys the sender's delivery instructions and is
mostly* considered immutable by the Broker.  After all, the Broker
might be just one of many intermediaries, and just because you wish
one Broker to countermand the persistence setting, does not mean you
want the same to apply to all intermediaries that follow. So the fact
that delivered message header does not reflect the overrides
persistence is expected.  Management just offers a view onto the
message header so again, it shows what the sender sent.

* different versions of AMQP have different rules.

Hope this helps.



The feature overrides the message's persistence setting to true if set
ALWAYS, and false if set NEVER.  If set DEFAULT, the sender's original
persistence wishes are respected.

On 21 March 2018 at 16:51, Bryan Dixon  wrote:
> Alex your response about queue attribute 'messageDurability' isn't what I had
> set to NEVER - it was the Persist Messages? attribute that I set to NEVER.
> I want to make sure I'm on the same page as you guys and I'll provide some
> screen shots to show what I did and saw.
>
> Firstly, my original post was referring to the attribute 'Message persistent
> override' from this documentation:
> https://qpid.apache.org/releases/qpid-broker-j-7.0.2/book/Java-Broker-Management-Managing-Queues.html.
>
> There is a 'Durable' attribute documented on that page also and my current
> setting is enabled (checked on the admin UI) but that wasn't what I wanting
> to change/test.
>
> Using the web admin UI I changed a queue's Persist Messages? value to NEVER
> - see this screen shot
> 
>
> I then ran this Java code using Qpid JMS 0.30.0 jars:
> ConnectionFactory connectionFactory = new JmsConnectionFactory(brokerUrl);
> Connection connection = connectionFactory.createConnection(user, pwd);
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> Destination destination =
> session.createQueue("app_attach_ehcacheReplicateQueue");
> MessageProducer messageProducer = session.createProducer(destination);
> TextMessage message = session.createTextMessage("Hello world! " + new
> Timestamp(System.currentTimeMillis()));
> messageProducer.send(message);
>
> It published the message to the queue and when I view the message via the
> web admin UI it has Persistent: true - see this screen shot
>  .
> I expected it to be Persistent: false based upon my change to NEVER and what
> I understood from the documentation.
>
> Also, when I ran this Java code (using JMS 0.30.0 again), it returned a
> value of 2 which indicates it is a persistent message:
> MessageConsumer messageConsumer = session.createConsumer(destination);
> TextMessage message = (TextMessage)messageConsumer.receive();
> System.out.println(String.format("persist?: %s",
> message.getJMSDeliveryMode()));
>
> However, after reading Alex's response of ' Thus, on broker restart the
> queue entries would be removed. ' I thought I would see what would happen to
> the message after the broker restart.  When I restarted the broker the
> message was gone.
>
> So now I'm actually a little more confused that I originally was but perhaps
> I'm not fully understanding this.   Being that the message was marked as
> Persistent (even though I didn't want it to be) and the Queue is marked as
> Durable (the checkbox is checked on the web admin UI), the message was lost
> which doesn't seem right?
>
> The virtual host environment I have is a 3 VirtualHostNode setup for HA.  I
> didn't test this on a single VirualHost node.
>
> Thanks
> Bryan
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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

[SECURITY] Apache Qpid Broker-J - response to CVE-2017-7525 - Deserialisation vulnerability in jackson-databind

[Keith W]

Hello

Apache Qpid Broker-J utilises the jackson-databind [1] component for
the purposes of persisting configuration and interpreting the payloads
of some network requests.  Vulnerability CVE-2017-7525 [2] was
recently published against the  jackson-databind component.

Whilst Apache Qpid Broker-J distributions include a version of
jackson-databind that is affected by the vulnerability, it is believed
that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this
vulnerability.  This is because Broker-J code never enables Jackson's
polymorphic deserialisation features: specifically it never makes
calls to Object#enableDefaultTyping(...) nor does it use
TypeResolverBuilders or annotations that enable the feature.

The Broker-J versions involved are:

* Apache Qpid Broker-J 7.0.0 - 7.0.2 included jackson-databind 2.8.7.
* Apache Qpid Broker-J 6.0.0 - 6.1.5 included jackson-databind 2.5.3.

The Apache Qpid project plans to put out new releases (7.0.3 and 6.1.6) of
the Broker-J soon.  These will include a newer release of  jackson-databind that
includes the fix for CVE-2017-7525.

Kind regards, Keith Wall.

[1] https://github.com/FasterXML/jackson-databind
[2] https://nvd.nist.gov/vuln/detail/CVE-2017-7525

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

Re: [Java Broker] Select certificate from broker keystore

[Keith W]

Hi Tomas,

It should not be too hard to separate out a defect fix from the work
of QPID-7567.   I will look to include this in a 7.0.3 which should
not be too far away.

Kind regards, Keith.

On 15 March 2018 at 17:06, Rob Godfrey  wrote:
> Hi Tomas,
>
> there is/was a bug in the broker whereby it would always pick the first
> certificate rather than the one with the correct alias.  I fixed the bug as
> part of QPID-7567[1] last year, however I think that is only on master (and
> scheduled for 7.1) and hasn't been backported to 7.0.x.
>
> -- Rob
>
> [1] https://issues.apache.org/jira/browse/QPID-7567
>
> On 15 March 2018 at 15:03, Vavricka  wrote:
>
>> Hi,
>>
>> *I generate multiple self-signed certificates by:*
>>
>> keytool -genkeypair -alias pc18379_1 -dname CN=pc18379 -validity 1096
>> -keysize 2048 -keyalg RSA -sigalg SHA512withRSA -keypass '123456'
>> -storepass
>> 123456 -deststoretype PKCS12 -keystore pc18379_1.jks
>> keytool -genkeypair -alias pc18379_2 -dname CN=pc18379 -validity 1096
>> -keysize 2048 -keyalg RSA -sigalg SHA512withRSA -keypass '123456'
>> -storepass
>> 123456 -deststoretype PKCS12 -keystore pc18379_2.jks
>> keytool -genkeypair -alias pc18379_3 -dname CN=pc18379 -validity 1096
>> -keysize 2048 -keyalg RSA -sigalg SHA512withRSA -keypass '123456'
>> -storepass
>> 123456 -deststoretype PKCS12 -keystore pc18379_3.jks
>>
>> Each generated keypair has own keystore.
>>
>> *I export private keys to keystore which broker will use by:*
>>
>> keytool -importkeystore -srckeystore pc18379_1.jks -srcstoretype PKCS12
>> -storepass '123456' -srcstorepass '123456' -alias pc18379_1 -deststoretype
>> PKCS12 -destkeystore keystore
>> keytool -importkeystore -srckeystore pc18379_2.jks -srcstoretype PKCS12
>> -storepass '123456' -srcstorepass '123456' -alias pc18379_2 -deststoretype
>> PKCS12 -destkeystore keystore
>> keytool -importkeystore -srckeystore pc18379_3.jks -srcstoretype PKCS12
>> -storepass '123456' -srcstorepass '123456' -alias pc18379_3 -deststoretype
>> PKCS12 -destkeystore keystore
>>
>> *I export public certificates by:*
>>
>> keytool -exportcert -keystore pc18379_1.jks -storepass '123456' -alias
>> pc18379_1 -rfc -file pc18379_1.crt
>> keytool -exportcert -keystore pc18379_2.jks -storepass '123456' -alias
>> pc18379_2 -rfc -file pc18379_2.crt
>> keytool -exportcert -keystore pc18379_3.jks -storepass '123456' -alias
>> pc18379_3 -rfc -file pc18379_3.crt
>>
>> *I create truststores for clients by:*
>>
>> keytool -import -alias pc18379_1 -file pc18379_1.crt -storepass '123456'
>> -noprompt -deststoretype PKCS12 -keystore pc18379_1.truststore
>> keytool -import -alias pc18379_2 -file pc18379_2.crt -storepass '123456'
>> -noprompt -deststoretype PKCS12 -keystore pc18379_2.truststore
>> keytool -import -alias pc18379_3 -file pc18379_3.crt -storepass '123456'
>> -noprompt -deststoretype PKCS12 -keystore pc18379_3.truststore
>>
>> *List of certificates in "keystore" (keystore broker will use)*
>>
>> Enter keystore password:
>> Keystore type: JKS
>> Keystore provider: SUN
>>
>> Your keystore contains 3 entries
>>
>> Alias name: pc18379_1
>> Creation date: Mar 15, 2018
>> Entry type: PrivateKeyEntry
>> Certificate chain length: 1
>> Certificate[1]:
>> Owner: CN=pc18379
>> Issuer: CN=pc18379
>> Serial number: 54f1c168
>> Valid from: Thu Mar 15 14:05:07 CET 2018 until: Mon Mar 15 14:05:07 CET
>> 2021
>> Certificate fingerprints:
>>  MD5:  60:6C:94:B6:5D:18:C3:AC:89:56:3F:A9:A2:70:83:37
>>  SHA1: 0D:D4:14:24:E6:92:35:B7:5B:A3:71:A7:BF:45:B3:6C:37:65:7F:4E
>>  SHA256:
>> 79:F0:77:65:27:93:5C:D0:55:73:42:B6:2D:4E:75:94:9A:64:6A:35:
>> 7C:12:4F:B0:CD:82:D7:89:96:8F:88:59
>> Signature algorithm name: SHA512withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>> Version: 3
>>
>> Extensions:
>>
>> #1: ObjectId: 2.5.29.14 Criticality=false
>> SubjectKeyIdentifier [
>> KeyIdentifier [
>> : 87 A5 26 94 CC 30 E8 63   66 61 87 1A 83 29 E7 63  ..&..0.cfa...).c
>> 0010: EE 16 2D B6..-.
>> ]
>> ]
>>
>>
>>
>> ***
>> ***
>>
>>
>> Alias name: pc18379_2
>> Creation date: Mar 15, 2018
>> Entry type: PrivateKeyEntry
>> Certificate chain length: 1
>> Certificate[1]:
>> Owner: CN=pc18379
>> Issuer: CN=pc18379
>> Serial number: 23e58c32
>> Valid from: Thu Mar 15 14:06:38 CET 2018 until: Mon Mar 15 14:06:38 CET
>> 2021
>> Certificate fingerprints:
>>  MD5:  15:71:70:31:43:11:D9:15:3B:5B:E7:F0:DD:AB:96:DB
>>  SHA1: D6:37:E3:4B:75:C7:9E:4B:D2:92:5C:50:92:DB:71:17:BE:58:FC:2F
>>  SHA256:
>> 52:88:88:AA:AE:C3:68:88:02:4D:CA:4E:32:76:DF:98:09:B9:03:9A:
>> AB:3E:C1:CF:69:6C:B2:B2:97:D8:87:ED
>> Signature algorithm name: SHA512withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>> Version: 3
>>
>> Extensions:
>>
>> #1: ObjectId: 2.5.29.14 Criticality=false
>> SubjectKeyIdentifier [
>> 

Re: qpid proton-cpp windows

[Keith W]

On 15 March 2018 at 13:42, Alan Conway  wrote:
>
>
> On Thu, Mar 15, 2018 at 9:28 AM, Baptiste Robert
>  wrote:
>>
>> Hello everybody,
>>
>> I currently have an issue with the qpid-proton c++ implementation on
>> windows. I can't connect to a Java broker with an authenticationproviders
>> set to : PlainPasswordFile.
>>
>> I built the simple_send examples and I can send messages to the broker if
>> authenticationproviders is set to Anonymous. As soon as I reactivate
>> PlainPasswordFile then I do not have any exception and exit code is set to
>> 1, no messages are sent, and Y is display in the console.
>
>
> If you are using the SASL plain mechanism without TLS/SSL you also need to
> set the connection_option sasl_allow_insecure_mechs(true)

Likewise, Broker-J won't offer the PLAIN SASL mechanism over a non-TLS
port to a peer.   If you don't want to use TLS, it can be overridden
using instructions that talk about overriding secureOnlyMechanisms
you'll find here:

https://qpid.apache.org/releases/qpid-broker-j-7.0.2/book/Java-Broker-Security.html#Java-Broker-Security-Authentication-Providers

>
> By default, SASL will disallow mechanisms that send plain-text passwords
> unless the connection is encrypted - even though you will see PLAIN listed
> in the set of allowed mechanisms from the server, it will ignored by the
> client.
>
> See the attached example which lets you play with SASL settings. Also a tip:
> set PN_TRACE_FRM=1 in your environment to get more information about the
> connection negotiation, including  some SASL info.
>
>>
>> Maybe I miss a dependency ?
>>
>> Baptiste
>
>
>
>
> -
> 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 JMS 0.30.0

[Keith W]

+1

* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_162 on Mac OS X 10.11.6)
* ran Broker-J's JMS test suite (qpid-systests-jms_2.0 &
qpid-systests-jms_1.1 - master) against the staged Maven artefacts

On 27 February 2018 at 08:56, Jakub Scholz  wrote:
> +1 ... I used the staging repo and run tests against different versions of
> the C++ broker (including master)
>
> On Mon, Feb 26, 2018 at 1:18 PM, Robbie Gemmell 
> wrote:
>
>> Hi folks,
>>
>> I have put together a spin for a 0.30.0 Qpid JMS client release,
>> please give it a test out and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/jms/0.30.0-rc1/
>>
>> The maven artifacts are also staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1131
>>
>> The JIRAs assigned are:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12314524=12342544
>>
>> Regards,
>> Robbie
>>
>> P.S. If you want to test it out using maven (e.g with the examples
>> src, or your own things), you can temporarily add this to your poms to
>> access the staging repo:
>>
>>   
>> 
>>   staging
>>   https://repository.apache.org/content/
>> repositories/orgapacheqpid-1131
>> 
>>   
>>
>> The dependency for the client itself would then be:
>>
>>   
>> org.apache.qpid
>> qpid-jms-client
>> 0.30.0
>>   
>>
>> -
>> 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 Broker-J 7.0.2

[Keith W]

+1.

My testing was:

1) Verified the md5/sha checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profile mms/bdb 0-9/1.0 from source bundle (Qpid JMS
Client 0.26.0/0.29.0)
5) Generally kicked the tyres within the Web Management Console using
Broker from the tar,gz bundle
6) Spun up an embedded Broker-J using the staged maven artefacts.


On 27 February 2018 at 14:57, Oleksandr Rudyy  wrote:
> Hi all,
>
> I built a release candidate for a Qpid Broker-J 7.0.2.
> Please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.0.2-rc1
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1132
>
> The JIRAs currently assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12342782
>
> Regards,
> Alex
>
> P.S. For testing of maven broker staging repo artifacts, please add into to
> your poms the staging repo as below:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1132
> 
>   
>
>
> -
> 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-J 0.26.0

[Keith W]

+1

* Ran Apache RAT against the source bundle
* Built and ran tests from source (Java 1.8.0_162-b12, Mac OS X 10.11.6)
* Ran Broker-J's JMS client integrations test suites:
qpid-systests-jms_1.1,qpid-systests-jms_2.0,end-to-end-conversion-tests
using staged maven artefacts

On 22 February 2018 at 21:02, Timothy Bish  wrote:
> +1
>
> * Validated signatures and checksums
> * Checked for license and notice files in binary and source archives
> * Ran mvn apache-rat:check to validate source files have licenses
> * Built from source and ran the tests
> * Build ActiveMQ, ActiveMQ Artemis and Qpid JMS using the staged bits and
> ran the AMQP tests
>
>
> On 02/22/2018 01:39 PM, Robbie Gemmell wrote:
>>
>> Hi folks,
>>
>> I have put together a spin for a Qpid Proton-J 0.26.0 release, please
>> test it and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.26.0-rc1/
>>
>> The maven artifacts are staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1130
>>
>> The JIRAs assigned are:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12342429
>>
>> Regards,
>> Robbie
>>
>> P.S. If you want to test things out using maven with your own build
>> you can temporarily add this to your poms to access the staging repo:
>>
>>
>>  
>>staging
>>
>> https://repository.apache.org/content/repositories/orgapacheqpid-1130
>>  
>>
>>
>> The dependency for proton-j would then be:
>>
>>
>>  org.apache.qpid
>>  proton-j
>>  0.26.0
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
>
> -
> 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-broker-j-7.0.0 failover is slow

[Keith W]

Bryan

Thanks for reporting the problem.  This is a defect in Broker-J 7.0.0
and 7.0.1.  The defect will cause startup to be delayed as you have
observed (5 seconds (cumulative) per queue or exchange using an
alternate binding).   The synchronous/asynchronous recoverer and
existence or not of consumers has no bearing.

The fix should be straight forward. I anticipate putting it out, as
part of a 7.0.2, soon.

Keith

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

On 20 February 2018 at 14:50, bryand  wrote:
> Answers to your questions..
>
> Could you please clarify whether you have seen "Gave up waiting"
> warnings with synchronous or asynchronous recoverer?
> - definitely when using synchronous but also pretty sure it was after I made
> the context change to use asynchronous recovery also.  I've been making
> several changes to get everything cleaned up so I can't remember about
> asynchronous for sure.
>
> Do you have full broker log with the warnings?  Can you share it?
> qpid.log 
>
> Did you connect consumers to DLQs whilst the VH messages were
> asynchronously recovered?
> - I never had any consumers connected to any of the DLQs
>
>
>
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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: Stopping JMS Connection with unprocessed prefetched messages results in message moved to DLQ

[Keith W]

On 14 February 2018 at 09:59, Keith W <keith.w...@gmail.com> wrote:
> Hi Bryan
>
>
>> So that brings me to the potential bug.  I found that when using the JMS
>> QueueBrowser it actually increments the Delivery Count for a message
>> everytime it is browsed.  That is why most of my source messages had a
>> Delivery Count > 0.  This doesn't seem right - a read-only Queue Browse
>> action shouldn't increment the Delivery Count if that same count is used to
>> determine if the message should be moved to the Alternate Binding (DLQ)
>> should it?
>
> Yes, that's a defect.  Thanks for reporting.  From my initial testing
> this morning the defect affects only queue browsers with the AMQP 0-10
> implementation (AMQP 0-8..0-91 and AMQP 1.0 are not affected).  The
> delivery count for messages delivered to browser gets incremented.
> For the message to be erroneously rerouted to a DLQ you would need a
> normal consumer on the queue too.  It would need to 'release' the
> message for delivery elsewhere (e.g. a rollback or abnormal
> disconnection).
>
> From an initial glance, the fix looks straightforward so I would hope
> we could include this in a 7.0.2.

Raised as:

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

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

Re: Stopping JMS Connection with unprocessed prefetched messages results in message moved to DLQ

[Keith W]

Hi Bryan

Yes, that's a defect.  Thanks for reporting.  From my initial


> So that brings me to the potential bug.  I found that when using the JMS
> QueueBrowser it actually increments the Delivery Count for a message
> everytime it is browsed.  That is why most of my source messages had a
> Delivery Count > 0.  This doesn't seem right - a read-only Queue Browse
> action shouldn't increment the Delivery Count if that same count is used to
> determine if the message should be moved to the Alternate Binding (DLQ)
> should it?

Yes, that's a defect.  Thanks for reporting.  From my initial testing
this morning the defect affects only queue browsers with the AMQP 0-10
implementation (AMQP 0-8..0-91 and AMQP 1.0 are not affected).  The
delivery count for messages delivered to browser gets incremented.
For the message to be erroneously rerouted to a DLQ you would need a
normal consumer on the queue too.  It would need to 'release' the
message for delivery elsewhere (e.g. a rollback or abnormal
disconnection).

>From an initial glance, the fix looks straightforward so I would hope
we could include this in a 7.0.2.

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

Re: qpid-broker-j-7.0.1 Simple LDAP and Group Providers

[Keith W]

Hello Bryan

On 12 February 2018 at 21:01, bryand  wrote:
> I'm trying to get Simple LDAP setup with qpid-broker-j-7.0.1.  I noticed in
> the documentation that you can configure group info with LDAP.

Yes, that's right.  The SimpleLDAP authentication provider allows you
to utilise group information from the DIT.

https://qpid.apache.org/releases/qpid-broker-j-7.0.1/book/Java-Broker-Security.html#Java-Broker-Security-LDAP-Provider

Once done, you can write ACL rules in terms of the DN of the group.
You must use quotation marks around the DN otherwise the ACL parser
will reject the commas. For instance:

ACL ALLOW-LOG "cn=mygroup,ou=acme" ACCESS VIRTUALHOST

>  If I do that  how does it work in conjunction with Group Providers?
>  I don't see a Group Provider for use with LDAP or am not understanding it.  
> Maybe I don't need
> to define a Group Provider if using LDAP group membership?

The use of the group provider is optional in this case.  One use case
for the group provider when using LDAP group is to map the DNs of the
group into a logical group name to keep your ACL rules simpler and
easier to maintain.

Unfortunately the ACL system within Broker-J needs a refresh and is
not a particularly friendly experience at the moment.  There is some
advice in the docbook which hopefully helps.  When writing a new ACL,
a workable approach is to begin with an rule-set containing only ACL
DENY-LOG ALL ALLat the Broker control point which will cause the
Broker to deny all operations with details of the denial logged. Build
up the ACL rule by rule, gradually working through the use-cases of
your system. Once the ACL is complete, consider switching the DENY-LOG
actions to DENY.

Hope this helps

Keith

>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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: proxy (firewall) issue

[Keith W]

Qian,

>From your description, it sounds like your firewall may be blocking
the none HTTP traffic.  Perhaps utilising the AMQP 1.0 web socket
binding is an option for you?

http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/amqp-wsb-v1.0.html

What AMQP 1.0 enabled products have you selected (client and server
side)?  Broker-J and the Qpid JMS Client have web socket support.

Hope this helps.

On 8 February 2018 at 14:55, Qian Cheng  wrote:
> Hello,
>
> we are currently facing a "big" simple problem. In one of our deploy 
> environment, there is a firewall between our glass fish server and  amqp 
> server. We can reach amqp server via proxy (HTTPS).
>
> My data here:
>
> environment: JAVA, AMQP 1.0
>
> Glassfish 4  (JAVA) using jms/amqp to send and consume messages with 
> "amqps://amqpRemoteUri" (topic)  => due to firewall not possible
>
> Curl -kv -x "user:passw...@proxy.xx.xx:8080 https://amqpRemoteUri; is ok 
> (from glassfish server)
>
> Is it possible to use any (additional) class to send / consume messages?
>
> Many thanks
> Qian
>
>
>

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

Re: [VOTE] Release Apache Qpid Broker-J 7.0.1

[Keith W]

+1.

My testing was:

1) Verified the md5/sha checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profile mms/bdb 0-9/1.0 from source bundle (Qpid JMS
Client 0.26.0 and 0.29.0)
5) Generally kicked the tyres within the Web Management Console.
6) Spun up an embedded Broker-J using the staged maven artefacts.

On 2 February 2018 at 14:43, Oleksandr Rudyy  wrote:
> Hi folks,
>
> I built a release candidate for a Qpid Broker-J 7.0.1.
> Please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.0.1-rc1
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1129
>
> The JIRAs currently assigned are:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12342094
>
> Regards,
> Alex
>
> P.S. For testing of maven broker staging repo artifacts, please add into to
> your poms the staging repo as below:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1129
> 
>   
>
>
> -
> 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: Broker-J statistics

[Keith W]

Hi Olivier V

Broker-J did expose a resetStatistics method  at the Broker and
VirtualHost level, but this for historical reasons,  these only ever
reset  a subset of statistics exposed by the Broker.  The newer
cumulative statistics were never included - which was always a bug.

The problem was that in order to reset all counters to zero
atomically, you would need to lock. This wasn't acceptable from a
performance perspective for what is an orthogonal concern.  Without
locking, you'd always risk your accounting being out.  One of the
use-cases for the statistics is demonstrating that the Broker has not
lost a message, something that could not be achieved if the tallies
weren't consistent.  The methods were removed by QPID-7799.

Keith.

On 2 February 2018 at 08:27, VERMEULEN Olivier
 wrote:
> Hello,
>
> Indeed it would work but ideally I'd like to be stateless thus the reset of 
> the statistics on the broker side.
> Or even better could these metrics be published directly by the broker ReST 
> API?
>
> Olivier V
>
> -Original Message-
> From: Olivier Mallassi [mailto:olivier.malla...@gmail.com]
> Sent: jeudi 1 février 2018 19:56
> To: users@qpid.apache.org
> Subject: Re: Broker-J statistics
>
> Hi Olivier
>
> AFAIR, I looked at the code at the UI console a couple of months ago and the 
> throughput per queues / exchange is calculated with a diff between total 
> messages every sec.
> This is done in the Js
>
> I guess that should answer your need
>
>
> Olivier.
>
> On Thu 1 Feb 2018 at 11:34, Olivier VERMEULEN 
> wrote:
>
>> Hello,
>>
>> We are currently implementing a messaging cluster with
>> dispatch-routers and Java brokers.
>> To be able to use it in production we are required to provide a few
>> statistics.
>> I see that I can use the broker ReST API to query some statistics on
>> the queues, exchanges,...
>> One of the statistics we are asked to provide is a the throughput of
>> messages and the throughput of data going in and out of a queue.
>> The ReST API gives me the total number of messages and total size of
>> data going in and out of the queue. But to be able to calculate a
>> throughput I need a way to reset those statistics.
>> I read something about that for Broker-J 6.1.X but didn't find any
>> reference to it for version 7. Is it expected? Is this use case
>> supported and if yes how?
>>
>> Thanks,
>> 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.
>
> -
> 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: [Proton-J] Create exchange / queues and bind them using proton-j library

[Keith W]

I think Dexter is using Qpid Broker-J.   Broker-J does have the
ability to dynamically create nodes (queues or exchanges) in response
to an attempt to form a link to an address. This is called node auto
creation and is something that is configured on the Broker. The client
side has no knowledge.  You could use it, say, to have a durable queue
appear the first time you attempt to receive from it.

Unfortunately, documentation is sparse for this feature and there is
no UI for it exposed in the management console at present.   However,
what was written on the JIRA and associated mailing list post (linked
within the JIRA's description) should help get going.  If not, let us
know what you are trying to achieve and I'll try to guide you further.

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

Broker-J does implement the latest AMQP Management draft, but this is
a moving target and the API will be subject to further (probably
breaking) changes as the specification evolves.

Hope this helps.




On 31 January 2018 at 08:29, Gordon Sim  wrote:
> On 30/01/18 23:29, dexter wrote:
>>
>> Hi,
>>
>> I'm trying to create dynamically an exchange type topic and some queues
>> and
>> bind them with the topic using a bindingKey using the latest Java library
>> proton-j-0.25.0.jar on a Apache Qpid Broker-J 7.0.0 server.
>>
>> If the exchange / queues are in place (created using RabbitMQ library
>> amqp-client-5.1.2.jar) my app works. But I want to create the exchange and
>> the queues using only proton-j library, because is supports AMQP 1.0
>> Protocol.
>>
>> I searched over this forum and over the GitHub examples but I could not
>> find
>> a solution.
>>
>> As I understand Receiver and Sender have some properties to set address,
>> durability, expiryPolicy and more. The address is in the format of
>> "exchangeName/bindingKey".
>>
>> Does the proton-j library support ExchangeDeclare, QueueDeclare and
>> QueueBind ? If yes, is there and example ? If no, what library should I
>> use
>> to manage exchanges / queues on a Broker with AMQP 1.0 Protocol support ?
>
>
> Proton-j is an AMQP 1.0 implementation and AMQP 1.0 does not define
> ExchangeDeclare etc from older iterations of the protocol.
>
> There is no standard schema for managing AMQP 1.0 brokers. You will need to
> sue whatever your broker supports for that.
>
> With RabbitMQ you can create and bind a temporary queue with the address
> format '/exchange/my-exchange/my-routing-key' [1]. Not sure whether that
> will be of use to you in your system.
>
> [1]
> https://github.com/rabbitmq/rabbitmq-amqp1.0/blob/v3.7.3/README.md#routing-and-addressing
>
>
> -
> 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: JMS Client failover error stops message consumption

[Keith W]

Bryan

Thanks for the attachment.  I hope to have time to look in detail
later this week.  Hopefully there will be a workaround.   I mostly see
the failover feature used with transactional JMS applications so this
may explain why the problem you report is unfamiliar to me.

Keith.



On 25 January 2018 at 19:29, bryand  wrote:
> I have been doing more testing of different scenarios regarding transacted
> sessions and different acknowledgement nodes and here is what I've found
> regarding this topic/behavior:
>
> My initial tests (and what I provided logs for) didn't use transactions and
> used auto acknowledge:
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>
> I also tested with client acknowledgement:
> Session session = connection.createSession(false,
> Session.CLIENT_ACKNOWLEDGE);
> and had the same behavior occur - message consumption stopped after the
> second failover.
>
> I then tested with using transactions (which is our normal use case but not
> 100% of the time):
> Session session = connection.createSession(transacted,
> Session.SESSION_TRANSACTED);
> and this test was successful.  I failed over multiple times (at least 3) and
> each time message consumption continued.  Messages that could not be
> committed because a failover was in progress were redelivered correctly once
> the client connected to the new master node.
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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: JMS Client failover error stops message consumption

[Keith W]

Bryan

I haven't seen failover exhibit this problem before.   The
reconnection logic awaits the dispatcher (a session scoped thread
which invokes your message listen) to finish delivery of the last
message to your application before completing the reconnection.  The
dispatcher close allows a period of 1000ms for the dispatcher to
complete its work before timing out.   You could try increasing the
timeout (system property -DDISPATCHER_SHUTDOWN_TIMEOUT_MS=).   However, as you say you message listener does not
more than log a message I suspect there might be something else going
on.  If increasing the timeout doesn't help, share a complete log
captured at DEBUG level and I'll try and help further.

HTH
Keith.



On 24 January 2018 at 18:44, bryand  wrote:
> I'm using broker-j-7.0.0 and apache-qpid-jms-0-x-6.3.0.  For broker-j I have
> HA setup with 3 brokers and have been testing failover by simply starting
> and stopping the virtual host node on a random broker.  Usually failover on
> my simple JMS message consumer is successful and message consumption
> continues but occasionally I'll receive the following exception on my
> consumer and it no longer receives messages:
> java.lang.RuntimeException: Dispatcher did not close down within the timeout
> of 1000 ms.
>
> My simple java client code is this..
>
> String brokerUrl =
> "amqp:///spgqpiddev?failover='roundrobin?cyclecount='2''='tcp://spgappdevmutil:5672?retries='3'='1000';tcp://appprd02:5672?retries='3'='1000';tcp://appprd02:5682?retries='3'='1000''";
>
> ConnectionFactory connectionFactory = new AMQConnectionFactory(brokerUrl);
>
> String user = "appuser";
> String pwd = "";
>
> Connection connection = connectionFactory.createConnection(user, pwd);
>
> connection.start();
>
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>
> String queueName = "app_testcluster";
>
> Destination destination = AMQDestination.createDestination(queueName,
> false);
>
> MessageConsumer messageConsumer = session.createConsumer(destination);
> // this MsgListener class simply prints out messages received.
> messageConsumer.setMessageListener(new MsgListener());
>
> The full stacktrace is:
> count: 500, id: ID:6c8f4df0-c8df-3751-86ee-75cef258de69, ts: 2018-01-24
> 09:58:49.718, lastTimestamp: 1516805929718, body: null
> 2018-01-24 13:23:58,820 [10.0.51.42:5672] - ERROR AMQConnectionDelegate_0_10
> - error during failover
> org.apache.qpid.transport.ConnectionException: connection closed
> at org.apache.qpid.transport.Connection.send(Connection.java:414)
> at org.apache.qpid.transport.Session.send(Session.java:588)
> at org.apache.qpid.transport.Session.invoke(Session.java:804)
> at org.apache.qpid.transport.Session.invoke(Session.java:613)
> at
> org.apache.qpid.transport.SessionInvoker.sessionAttach(SessionInvoker.java:29)
> at org.apache.qpid.transport.Session.attach(Session.java:290)
> at org.apache.qpid.transport.Session.resume(Session.java:300)
> at org.apache.qpid.transport.Connection.resume(Connection.java:524)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.resubscribeSessions(AMQConnectionDelegate_0_10.java:288)
> at
> org.apache.qpid.client.AMQConnection.resubscribeSessions(AMQConnection.java:1480)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10$2.run(AMQConnectionDelegate_0_10.java:363)
> at
> org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1959)
> at
> org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1947)
> at
> org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1926)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:340)
> at org.apache.qpid.transport.Connection.closed(Connection.java:601)
> at 
> org.apache.qpid.transport.network.Assembler.closed(Assembler.java:113)
> at
> org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:219)
> at 
> org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225)
> at java.lang.Thread.run(Thread.java:745)
> 2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO  FailoverRoundRobinServers
> -  Checking failoverAllowed() 
> 2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO  FailoverRoundRobinServers
> - Cycle Servers:
> Cycle Retries:2
> Current Cycle:0
> Server Retries:3
> Current Retry:0
> Current Broker:2
> tcp://spgappdevmutil:5672?connectdelay='1000'='3'
> tcp://appprd02:5672?connectdelay='1000'='3'
>>tcp://appprd02:5682?connectdelay='1000'='3'
>
> 2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO  FailoverRoundRobinServers
> - 
> 2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO  FailoverRoundRobinServers
> - Trying tcp://appprd02:5682?connectdelay='1000'='3'
> 2018-01-24 13:23:58,823 [10.1.1.119:5682] - INFO  

Re: Broker-J HA with just 2 brokers

[Keith W]

Hello Bryan

Broker-J does support a active/passive groups formed of two nodes.

In a two node group, both nodes to be online in order to maintain
quorum.If one node were to fail business will stop. In order to
restore service from a single node, a 3rd party (script and/or human)
needs to intervene and set "Allow to Operate Solo" on the surviving
node.  This overrides the normal quorum requirement and allows service
continue from the one.   It is important to manage the setting of
"Allow to Operate Solo" carefully. If you were to set it on both nodes
and the network link between the two nodes be lost both nodes would
become master and process transactions independently (i.e.a  split
brain).  Read more here:

https://qpid.apache.org/releases/qpid-broker-j-7.0.0/book/Java-Broker-High-Availability-OverviewOfHA.html
https://qpid.apache.org/releases/qpid-broker-j-7.0.0/book/Java-Broker-High-Availability-Behaviour.html

"Required Minimum Number Of Nodes" actually applies to groups of three
or more.  It has no effect on a two node group (and is hidden from the
UI when  two node group is configured).  It is used to reduce the
quorum requirement in groups of three or more allows service to be
restored in extraordinary failure scenarios.  Obviously the same care
needs to be taken with this setting to avoid the possibility of
split-brain.

Whilst it is technically possible to host a group of three nodes
across two JVMs, you defeat the purpose of a three node group - the
ability to recover -automatically- from a single node failure.

Hope this helps.

Keith


On 23 January 2018 at 20:23, bryand  wrote:
> I'm just getting started with QPid and want to setup HA with Broker-J.  We
> are trying to replace our current ActiveMQ environment where we use a Master
> Slave approach for HA and just have 2 nodes running.  I really want to just
> have 2 nodes with Broker-J also because that setup has been working fine for
> us with ActiveMQ and I really don't want to have 3 VMs used for both our
> Test and Production Broker-J environments.
>
> I've read the documentation regarding Required Minimum Number Of Nodes and
> Allow to Operate Solo and it sounds as if those options are really meant for
> manual use in a 2 node HA environment (for example you shouldn't have Allow
> to Operate Solo enabled for more than one node at a time).
>
> Is it possible to have a 3 node environment just using 2 brokers (so I can
> just have 2 VMs for each of our Test and Production environments)?  For
> example can I have one VirtualHostNode on Broker A and then 2
> VirtualHostNodes on Broker B.  I've set this up but am not having much luck
> getting either node on Broker B accept requests from a client (when I stop
> the node on Broker A) even though the Virtual Host is reporting as ACTIVE on
> Broker B - the client is reporting that the Virtual Host is unknown.
> However as soon as I start the Virtual Host Node on Broker A, I can
> successfully have my (JMS) client connect to the MASTER Virtual Host Node on
> Broker B.
>
> Anyway I'm wondering if the setup I'm trying (2 VMs with 1 Broker running on
> each but 1 of the brokers has 2 VirtualHostNodes for the VirtualHost) is
> even valid or do I really need to have 3 VMs with 1 Broker each running?
> Just trying to see if I can keep the same 2 VM setup we have for ActiveMQ.
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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 JMS 0.29.0

[Keith W]

+1

* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_151 on Mac OS X 10.11.6)
* ran Broker-J JMS test suite (master) against the staged Maven artefacts

On 20 January 2018 at 13:52, Jakub Scholz  wrote:
> +1 ... I used the staging repo and run my tests against different versions
> of C++ broker.
>
> On Fri, Jan 19, 2018 at 1:30 PM, Robbie Gemmell 
> wrote:
>
>> Hi folks,
>>
>> I have put together a spin for a 0.29.0 Qpid JMS client release,
>> please give it a test out and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/jms/0.29.0-rc1/
>>
>> The maven artifacts are also staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1128
>>
>> The JIRAs currently assigned are:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12314524=12342310
>>
>> Regards,
>> Robbie
>>
>> P.S. If you want to test it out using maven (e.g with the examples
>> src, or your own things), you can temporarily add this to your poms to
>> access the staging repo:
>>
>>   
>> 
>>   staging
>>   https://repository.apache.org/content/
>> repositories/orgapacheqpid-1128
>> 
>>   
>>
>> The dependency for the client itself would then be:
>>
>>   
>> org.apache.qpid
>> qpid-jms-client
>> 0.29.0
>>   
>>
>> -
>> 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: Java Broker performance

[Keith W]

Hi Tomas,

The work for QPID-8032 is done on master.   If you could repeat your
test-case with Broker-J compiled for master and let us know how
performance changes (improves, hopefully a lot).  Once I have heard
back from you I'll look to have this included in a 7.0.1 very soon.

Kind regards, Keith Wall.

On 26 November 2017 at 14:54, Keith W <keith.w...@gmail.com> wrote:
> Hi Tomas
>
> Thanks for the attachments.
>
> With your Broadcaster code, which sends persistent messages
> asynchronously, I do see inferior performance from Broker J than the
> CPP Broker.  I am using proton master (fa80534)
>
> Currently for this use-case, Broker-J commits synchronously after each
> delivery (see StandardReceivingLinkEndpoint#receiveDelivery.  The
> pertinent part is its use of an AutoCommitTransaction and the fact
> that AutoCommitTransaction#enqueue uses a synchronous #commitTran) and
> this will explain some (if not all) of the performance difference.  As
> Rob mentioned on the 10th November in this thread, the older protocols
> already have an optimisation for this use-case (involving
> AsyncAutoCommitTransaction) which should improve performance on the
> AMQP 1.0 path.   This was raised as QPID-8032. I try and include this
> in a 7.0.1 soon.
>
> This doesn't explain your observation about performance when using
> Qpid JMS Client which is doing a synchronous send of persistent
> messages, but as I commented above, I cannot reproduce the problem: I
> see very similar performance for Broker-J and CPP on my hardware.
>
> cheers Keith.
>
> On 24 November 2017 at 13:06, Tomas Soltys <tomas.sol...@gmail.com> wrote:
>> Hi Keith,
>>
>> Please find attached  cpp_vs_java.gz
>> <http://qpid.2158936.n2.nabble.com/file/t365522/cpp_vs_java.gz>  . This
>> archive contains:
>> * *java* - setup of Java broker (v7.0.0)
>> * *cpp* - setup of C++ broker (v1.36.0)
>> * *proton-client* - C++client based on Qpid proton (v0.18.1)
>> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
>> each) to Java broker
>> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
>> each) to C++ broker
>>
>> One thing I've noticed in logs is that C++ broker is sending dispositions in
>> chunks of 5 whereas Java broker does this for each message separately.
>>
>> Best regards,
>> Tomas
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>>
>> -
>> 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

[SECURITY] [CVE-2017-15702] Apache Qpid Broker-J Authentication Vulnerability on HTTP Ports

[Keith W]

CVE-2017-15702: Apache Qpid Broker-J authentication vulnerability on HTTP ports

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected: Versions 0.18 through 0.32

Description:

If the broker is configured with different authentication providers on
different ports one of which is an HTTP port, then the broker can be
tricked by a remote unauthenticated attacker connecting to the HTTP
port into using an authentication provider that was configured on a
different port.  The attacker still needs valid credentials with the
authentication provider on the spoofed port.  This becomes an issue
when the spoofed port has weaker authentication protection (e.g.,
anonymous access, default accounts) and is normally protected by
firewall rules or similar which can be circumvented by this
vulnerability.  AMQP ports are not affected.  Versions 6.0.0 and newer
are not affected.

Resolution:

Users of affected versions who have more than one port and different
authentication providers configured on them should upgrade to a
later unaffected version.

Mitigation:

If upgrading the broker is not possible then users should ensure all
their authentication providers offer an equal amount of protection.
In particular, authentication providers with default accounts and
those with anonymous access should be removed if other providers in
use require credentials.

References:

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

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

Re: Java Broker performance

[Keith W]

Hi Tomas

Thanks for the attachments.

With your Broadcaster code, which sends persistent messages
asynchronously, I do see inferior performance from Broker J than the
CPP Broker.  I am using proton master (fa80534)

Currently for this use-case, Broker-J commits synchronously after each
delivery (see StandardReceivingLinkEndpoint#receiveDelivery.  The
pertinent part is its use of an AutoCommitTransaction and the fact
that AutoCommitTransaction#enqueue uses a synchronous #commitTran) and
this will explain some (if not all) of the performance difference.  As
Rob mentioned on the 10th November in this thread, the older protocols
already have an optimisation for this use-case (involving
AsyncAutoCommitTransaction) which should improve performance on the
AMQP 1.0 path.   This was raised as QPID-8032. I try and include this
in a 7.0.1 soon.

This doesn't explain your observation about performance when using
Qpid JMS Client which is doing a synchronous send of persistent
messages, but as I commented above, I cannot reproduce the problem: I
see very similar performance for Broker-J and CPP on my hardware.

cheers Keith.

On 24 November 2017 at 13:06, Tomas Soltys  wrote:
> Hi Keith,
>
> Please find attached  cpp_vs_java.gz
>   . This
> archive contains:
> * *java* - setup of Java broker (v7.0.0)
> * *cpp* - setup of C++ broker (v1.36.0)
> * *proton-client* - C++client based on Qpid proton (v0.18.1)
> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
> each) to Java broker
> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
> each) to C++ broker
>
> One thing I've noticed in logs is that C++ broker is sending dispositions in
> chunks of 5 whereas Java broker does this for each message separately.
>
> Best regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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: Java Broker performance

[Keith W]

Hi Tomas,

Can I suggest that you share the logs from both brokers for the two
amq_send.sh test?   Also separately, I suggest a run of amq_send.sh
with a small number of message, say message-count 20, with Proton
trace logging enabled (export PN_TRACE_FRM=true) on the client side.
Repeat this with both Brokers and share.

With regard to Broker-J performance, we know that BDB will outperform
Derby for many use-cases.  The BDB plugin has received much more
tuning over the years than Derby.  I know you have already said you
tested with both earlier in the thread, but I wanted to point it out.

cheers Keith



On 24 November 2017 at 10:58, Tomas Soltys  wrote:
> Hi Robbie,
>
> I just realized that I placed my response to incorrect person. It supposed
> to be a reply to Keith's message.
>
> To your questions. The test was performed with C client based on proton
> 0.18.1. However, I got very similar results also with qpid-send tool which
> settles after each message.
>
> I've also tried sending using 0-10 and 1.0 protocol versions but no
> significant differences.
>
> I also executed test client based on Qpid JMS 0.23.0 with very similar
> results. In all cases C++ broker was able to settle and send acknowledgment
> way much faster than java broker.
>
> Is there something in the settings that can be tweaked to improve IO
> performance?
>
> Regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> 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

[RESULT] [VOTE] Release Qpid Java 6.1.5

[Keith W]

There were 4 binding +1 votes, with no other votes received. The vote
has passed.

https://lists.apache.org/thread.html/2aa1998d9ace98369df760643bae82b512e72b9608f2e1c4858ffc6a@%3Cusers.qpid.apache.org%3E

I will add the archives to the dist release repo and release the maven
staging repo shortly. I will update the website tomorrow once the
artifacts have had time to sync to the mirrors and maven central.

Kind regards,
Keith

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

Re: [VOTE] Release Apache Qpid CPP 1.37.0

[Keith W]

+1

- Verified the signature and checksum files.
- built from source on Ubuntu 16.04.3
- verified QPID-8041 against Qpid Broker-J v7.0.0.



On 22 November 2017 at 11:13, Robbie Gemmell  wrote:
> On 21 November 2017 at 18:20, Robbie Gemmell  wrote:
>> Hi folks,
>>
>> I have put together a spin for a Qpid CPP 1.37.0 release, please give
>> it a test out and vote accordingly.
>>
>> The source archive can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/cpp/1.37.0-rc1/
>>
>> The JIRAs currently assigned are:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12338808
>>
>> It is tagged as 1.37.0-rc1.
>>
>> Regards,
>> Robbie
>
> +1
>
> I checked things out as follows:
>  - Verified the signature and checksum files.
>  - Checked LICENCE+NOTICE files present.
>  - Ran the build and tests against Proton 0.18.1, on Fedora 26.
>  - Ran the JMS client HelloWorld example against the built broker.
>
> 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

[RESULT] [VOTE] Release Apache Qpid JMS AMQP 0-x 6.3.0

[Keith W]

There were 5 binding +1 votes, with no other votes received. The vote
has passed.

https://lists.apache.org/thread.html/67527d591d9831dbec98bc12de4b3755ed99fa3a6d37d594740408af@%3Cusers.qpid.apache.org%3E

I will add the archives to the dist release repo and release the maven
staging repo shortly. I will update the website tomorrow once the
artifacts have had time to sync to the mirrors and maven central.

Kind regards,
Keith

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

Re: [VOTE] Release Apache Qpid JMS AMQP 0-x 6.3.0

[Keith W]

> Comments:
> -The NOTICE file in the source release archive says Apache Qpid Java
> and should be updated going forward.
> -The slf4j-api details in the binary archive NOTICE can be removed
> going forward as its covered by the details in the LICENCE file
> already.
> -The directories in all the archives dont match their file names (sans
> extension), which seems like it was the intended name, e.g
> apache-qpid-jms-0-x-6.3.0-src isn't aligned with
> apache-qpid-jms-amqp-0-x-6.3.0-src.tar.gz
>

Thanks, these will be addressed by
https://issues.apache.org/jira/browse/QPID-8044

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

Re: [VOTE] Release Qpid Java 6.1.5 (RC1)

[Keith W]

+1.

Making my vote explicit

1) Verified the md5/sha checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profile mms 0-10 from source bundle and bdb.0-9-1
using BDB JE 7.4.5
5) Ran Joram test suite against the broker from binary distribution
artefact using the Qpid JMS Client 0.22.0.

No problems encountered.

On 20 November 2017 at 12:07, Oleksandr Rudyy <oru...@gmail.com> wrote:
> +1
>
> I performed the following tests:
> * built broker from sources and ran tests using profile 'java-mms.0-10'
> * verified signatures and checksums
> * started broker from tar.gz bundle
> * created and bound test queue using web management console
> * built examples in client bundle
> * ran successfully examples Hello/Spout/Drain against 6.1.5 broker
> using 6.1.5 client
>
>
> On 17 November 2017 at 17:31, Keith W <keith.w...@gmail.com> wrote:
>> Hi all,
>>
>> A bug-fix release candidate for the next release (6.1.5) of the Qpid
>> Java Components has been created.
>>
>> The list of defect fixes can be found in Jira:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.1.5
>>
>> Please test and vote accordingly.
>>
>> The source and binary archives can be grabbed from here:
>> https://dist.apache.org/repos/dist/dev/qpid/java/6.1.5-rc1
>>
>> Those files and the other maven artifacts are also staged for now at:
>>
>> https://repository.apache.org/content/repositories/orgapacheqpid-1124
>>
>> Kind regards
>>
>> P.S. If you want to test it out using maven (e.g with the examples src,
>> or your own things), you can temporarily add this to your poms to access
>> the staging repo:
>>
>>   
>> 
>>   staging
>>   
>> https://repository.apache.org/content/repositories/orgapacheqpid-1124
>> 
>>   
>>
>> -
>> 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

[VOTE] Release Qpid Java 6.1.5 (RC1)

[Keith W]

Hi all,

A bug-fix release candidate for the next release (6.1.5) of the Qpid
Java Components has been created.

The list of defect fixes can be found in Jira:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.1.5

Please test and vote accordingly.

The source and binary archives can be grabbed from here:
https://dist.apache.org/repos/dist/dev/qpid/java/6.1.5-rc1

Those files and the other maven artifacts are also staged for now at:

https://repository.apache.org/content/repositories/orgapacheqpid-1124

Kind regards

P.S. If you want to test it out using maven (e.g with the examples src,
or your own things), you can temporarily add this to your poms to access
the staging repo:

  

  staging
  
https://repository.apache.org/content/repositories/orgapacheqpid-1124

  

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

Re: [VOTE] Release Apache Qpid JMS AMQP 0-x 6.3.0

[Keith W]

+1

* ran apache-rat against source bundle
* built / ran tests from source bundle using Java 7
* ran org.apache.qpid.example.Hello from binary bundle using Java 7
* ran successfully Qpid Broker-J system tests (on master) using 6.3.0
stage artefacts

On 16 November 2017 at 14:17, Oleksandr Rudyy  wrote:
> +1
>
> I performed the following tests:
> * built successfully client from source distribution bundle
> * ran successfully Hello, Spout and Drain examples against Qpid
> Broker-J built from master
> * ran successfully Qpid Broker-J system tests (on master) using 6.3.0
> staging artefacts
> * verified checksums and signatures
>
> -
> 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: Java Broker performance

[Keith W]

On 15 November 2017 at 14:13, Gordon Sim <g...@redhat.com> wrote:
> On 10/11/17 18:11, Keith W wrote:
>>
>> I infer that CPP Broker must be optimistically sending the
>> Disposition back to the client before the data is sync'd, so that is
>> why you see better performance (but with a lesser guarantee).
>
>
> I don't believe that is the case. The c++ broker only sends back the
> disposition once confirmed by the store (and the linear store only confirms
> once synced).
>

Agreed. I retract my statement.  I've now tested Tomas's JMS
reproduction against the C++ Broker with linearstore with durable
queue and Broker-J on the same hardware.   I got similar throughput
numbers in both cases.



> Are you sure that (a) the store was in use and (b) you were waiting for
> acknowledgement of one message before sending the next (sending
> asynchronously is obviously faster)?
>

Tomas, can you tell us more?

>
> -
> 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: Welcome Chris Richardson as an Apache Qpid committer

[Keith W]

Indeed, welcome!

On 16 November 2017 at 07:57, Lorenz Quack  wrote:
> Welcome Chris,
>
> Good to have you on the team!
>
> On Wed, Nov 15, 2017 at 7:02 PM, Adel Boutros  wrote:
>
>> Welcome Chris!!
>> 
>> 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
>> !*
>>

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

Re: Java Broker performance

[Keith W]

The test is sending persistent messages so the broker is obliged to
write them to disk.  After the arrival of each message transfer, the
Broker-J awaits the sync'd to disk (after the write) before sending
the Disposition performative back to the client.  The Qpid JMS Client
is awaiting the Disposition, so it is only then that the
MessageProducer#send returns and the application can send the next
message.   I infer that CPP Broker must be optimistically sending the
Disposition back to the client before the data is sync'd, so that is
why you see better performance (but with a lesser guarantee).   If you
were to switch the Qpid JMS Client to jms.forceAsyncSend[1], I would
expect you would see greater performance.   Let me ask a higher level
question - what messaging guarantee does this application require?

[1] https://qpid.apache.org/releases/qpid-jms-0.27.0/docs/index.html

On 10 November 2017 at 15:50, Rob Godfrey  wrote:
> On 10 November 2017 at 16:39, Vavricka  wrote:
>
>> Hi,
>>
>> hardware:
>> * Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
>> * 16 GB RAM
>> * HDD ST500DM002-1BD142
>>
>> timings:
>> Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
>> messages per second. Interesting is when I increase message size to 10kB.
>> Messages per second are same but throughput is increased ten times.
>> When I use nonpersistent messages everything goes smooth. Thousand of 1kB
>> messages are sent within 1 second.
>>
>
> So, this is more what I would expect (in the sense that 6.1 will behave
> like 7.0 - the performance is unacceptable, but I think I understand it).
>
> I *think* the issue is that we have not yet implemented the optimisations
> in the 1.0 layer for non-transactional durable messages to be processed
> asynchronously.  Because of this the rate of message processing is
> dependent upon how many times fsync() can be called a second.  500/s is
> probably about right for a SAN, ~20 is what I saw from conventional hard
> drives; for SSDs with a battery backed write cache I've gotten > 1000/s.
> Because it is dependent upon the number of fsyncs rather than the
> throughput of the disk, increasing the message size will not affect the
> rate and thus you will see a linear improvement in throughput.
>
> Fixing this shouldn't actually be a huge change, and after it you should
> see something more like the C++ broker behaviour.  Since this isn't (I
> think) a regression between 7.0 and 6.1 I'd suggest that we progress with
> the 7.0 release and then quickly follow that with a 7.0.1 that introduces
> the necessary optimisation (we can essentially copy over the code from the
> 0-x protocol layers).
>
> -- Rob
>
>
>>
>> There are no extra JVM options, just the ones which are present in
>> bin/qpid-server file.
>>
>> Heap and direct memory on broker is also default - -Xmx512m
>> -XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger
>> ones
>> -Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in
>> messages
>> per second.
>>
>> Unfortunately vmstat gives same values pro CPU, I am sending at least top
>> output.
>>
>> 6.1.1:
>> %Cpu(s):  6.9 us,  0.3 sy,  0.0 ni, 68.5 id, 24.1 wa,  0.0 hi,  0.2 si,
>> 0.0
>> st
>>
>> 7.0.0:
>> %Cpu(s):  2.4 us,  0.4 sy,  0.0 ni, 71.2 id, 25.9 wa,  0.0 hi,  0.0 si,
>> 0.0
>> st
>>
>> When we tried on server where message store was stored on SAN disk, sending
>> of messages increased to 500 msg/sec. With C++ broker on same machine we
>> are
>> able to send 5000 msg/sec.
>>
>> ps. I cannot create queue in 7.0.0 version by webgui when queue contains
>> '.'
>> character, in 6.1.1 version queue with dot in name can be created by webgui
>>
>>
>> Keith Wall wrote
>> > Hi Tomas,
>> >
>> > Nor can I reproduce any discernible difference in performance between
>> > 6.1.1 and the 7.0.0 RC with your Java code.  I have not tried the C++
>> > yet.
>> >
>> > Can you share with us:
>> >
>> > * details of the hardware (including the storage) you are using for the
>> > test.
>> > * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0
>> > RC
>> > * any extra JVM options you are passing either client or broker side.
>> > * size of java heap (client side) and heap and direct memory (broker)
>> >
>> > Can I suggest that you collect vmstat type information for both runs
>> > and compare?   My expectation is that CPU usage, disk I/O, and network
>> > utilisation should be approximately equal between the two runs.
>> >
>> > cheers, Keith
>>
>>
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
>> f2158936.html
>>
>> -
>> 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 

Re: Java Broker performance

[Keith W]

Hi Tomas,

I'm testing with out of the box configuration.   I have tried your
configuration and still can't reproduce a slow down. I don't know your
ACL rules, but I added some.  The result was the same.
I'm curious to hear the answers to the questions I posed earlier.
Hopefully that will give us a clue.

Thanks Keith.


On 10 November 2017 at 13:51, Keith W <keith.w...@gmail.com> wrote:
> Hi Tomas,
>
> Nor can I reproduce any discernible difference in performance between
> 6.1.1 and the 7.0.0 RC with your Java code.  I have not tried the C++
> yet.
>
> Can you share with us:
>
> * details of the hardware (including the storage) you are using for the test.
> * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0 RC
> * any extra JVM options you are passing either client or broker side.
> * size of java heap (client side) and heap and direct memory (broker)
>
> Can I suggest that you collect vmstat type information for both runs
> and compare?   My expectation is that CPU usage, disk I/O, and network
> utilisation should be approximately equal between the two runs.
>
> cheers, Keith
>
>
> On 10 November 2017 at 11:12, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
>> Hi Tomas,
>>
>> on the producing side I cannot reproduce this difference on my laptop
>> (MacBook Pro, running OS X), and I'm unaware of any changes that were made
>> to the broker that would cause such a significant slowdown (I haven't
>> looked at consuming yet).
>>
>> I presume you are running these tests on the same hardware, with the same
>> JMS client version, and such...?
>>
>> -- Rob
>>
>> On 10 November 2017 at 10:11, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
>>
>>> Thanks Tomas,
>>>
>>> we'll look into this
>>>
>>> -- Rob
>>>
>>> On 10 November 2017 at 09:59, Vavricka <vavricka.to...@gmail.com> wrote:
>>>
>>>> C++ client code below
>>>>
>>>> #include 
>>>> #include 
>>>>
>>>> #include 
>>>> #include 
>>>> #include 
>>>> #include 
>>>> #include 
>>>> #include 
>>>> #include 
>>>> #include 
>>>> #include 
>>>>
>>>> class Broadcaster : public proton::messaging_handler
>>>> {
>>>>
>>>> private:
>>>>
>>>> std::string _account;
>>>> std::string _password;
>>>> std::string _host;
>>>> unsigned int _port;
>>>> unsigned int _count;
>>>> unsigned int _size;
>>>> unsigned int _sent;
>>>> unsigned int _confirmed;
>>>> std::string _exchange;
>>>> std::string _routingKey;
>>>> proton::sender _sender;
>>>>
>>>> public:
>>>>
>>>> explicit Broadcaster(const std::string ,
>>>>  const std::string ,
>>>>  const std::string ,
>>>>  unsigned int port,
>>>>  const std::string ,
>>>>  const std::string ,
>>>>  unsigned int count,
>>>>  unsigned int size)
>>>> : _account(account)
>>>> , _password(password)
>>>> , _host(host)
>>>> , _port(port)
>>>> , _count(count)
>>>> , _size(size)
>>>> , _sent(0)
>>>> , _confirmed(0)
>>>> , _exchange(exchange)
>>>> , _routingKey(routingKey)
>>>> {
>>>> }
>>>>
>>>> void on_container_start(proton::container )
>>>> {
>>>> proton::connection_options connectionOptions;
>>>> connectionOptions.sasl_allow_insecure_mechs(true);
>>>> connectionOptions.sasl_allowed_mechs("PLAIN");
>>>> c.client_connection_options(connectionOptions);
>>>>
>>>> std::string url = "amqp://" + _account + ":" + _password + "@" +
>>>> _host + ":" + std::to_string(_port) + "/" + _exchange;
>>>>
>>>> _sender = c.open_sender(url);
>>>> }
>>>>
>>>> void on_sendable(proton::sender )
>>>> {
>>>