Re: Virtualhost Initial Configuration

[Rob Godfrey]

In order to help, you'll need to be a bit more explicit in terms of what
you are trying to achieve in the virtual host configuration and exactly in
what way it is "not working",

-- Rob

On Wed, 27 Mar 2024 at 17:36, Faisal Shaukat  wrote:

> Dear Sir/Madam,
>
> I am trying to use Apache Qpid in my integration test. I have an in Memory
> instance of Qpid. I want to define an exchange,queue and a routing key.
> However, the virtual host initial configuration from the documentation is
> not working. Can you please help me and let me know how can i extend the
> initial configuration so that i can define exchange, queue and a routing
> key.
>
> Many Thanks in Advance!
>
> Best Regards,
> Faisal
>
> Gesendet von Mail für
> Windows
>
>

Re: [VOTE] Release Qpid Broker-J 9.0.0 (RC2)

[Rob Godfrey]

+1

built and ran on my (Intel) Mac using JDK 11
ran mms and bdb system tests
verified signatures and checksum files
used console to perform a few basic operations

-- Rob

On Tue, 15 Nov 2022 at 08:19, Tomas Vavricka  wrote:

> +1
>
> * verified signatures and checksum files
> * extracted source bundle using 'tar -xvf' or 'mc' on Ubuntu 22.04 and
> using 7-zip (Windows 10)
> * executed mvn apache-rat:check
> * executed the build and tests with -DskipITs parameter on JDK 11/17
> * started Qpid Broker-J, created queues/exchanges/ports/... via REST API
> * sent and received messages using Qpid JMS Client
>
> Tomas
>
> On 2022/11/14 11:51:14 Tomas Vavricka wrote:
> > Hi all,
> >
> > I built release artefacts for Qpid Broker-J version 9.0.0 RC2.
> > 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/9.0.0-rc2/
> >
> > The maven artifacts are also staged at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1251/
> >
> > The new version brings a number of improvements and bug fixes.
> > You can find the full list of JIRAs included in the release here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12348607
> >
> > Regards,
> > Tomas
> >
> > 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-1251/
> 
> > 
> > 
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: QPID Broker-J Java 11

[Rob Godfrey]

To be clear, are we talking about changing the required minimum version of
Java required to run Qpid Broker-J?  I think it's probably about time, but
that would probably deserve updating the major version number (I think
we've done that every time we've upped the required Java version
previously).

-- Rob

On Mon, 28 Mar 2022 at 22:31, Oleksandr Rudyy  wrote:

> +1
>
> Please feel free to migrate Qpid Broker-J to java 11. I cannot think
> about any issue with an update to java 11.
>
> Kind Regards,
> Alex
>
> On Sat, 26 Mar 2022 at 07:53, Daniil Kirilyuk 
> wrote:
> >
> > Hi Colleagues,
> >
> >
> >
> > We'd like to update the java version from 8 to 11 for QPID Broker-J.
> > Although Java 8 is still being supported, Java 11 is already actively
> used
> > in development as well as in production environments.
> >
> > There are several issues pointed out to ensure support for java 9 and 11
> -
> > QPID-8241, QPID-7885, QPID-8267.
> >
> > Are there any implications to consider? Are there any tasks to be done or
> > issues to be solved before updating the java version?
> >
> >
> >
> > Kind regards,
> >
> > Daniil Kirilyuk
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Broker-J: several authentication providers on one port

[Rob Godfrey]

Rather than changing the model with all the extra work required to perform
upgrades, etc... Would it make sense/be possible to simply define a new
"composite authentication provider" which just contained an ordered list of
other authentication providers which it would delegate to?  This would seem
to be potentially a much smaller change.

-- Rob

On Thu, 23 Sept 2021 at 08:38, Daniil Kirilyuk 
wrote:

> Hi Colleagues,
>
> We're using Apache Qpid Broker-J with SCRAM SHA authentication provider for
> AMQP port and external (SSL client certificates) authentication provider
> for AMQPS port.
>
> In the foreseeable future authentication mechanisms should be changed to
> LDAP. But due to the large number of clients the migration of accounts to
> LDAP will proceed over some (probably long) period of time.
>
> Requirement to us is to perform authentication either against the local
> file-based database of users (for clients who don't have an LDAP migrated
> account yet) or against LDAP (for clients already migrated). All clients
> should access Broker-J via the same port.
>
> At the moment there is no possibility to assign more than one
> authentication provider to the broker port.
>
> We were thinking about adding a possibility to configure for a broker port
> an ordered list of authentication providers, which will authenticate
> clients in the order defined till authentication success. Would such a
> change be acceptable from the architectural point of view? Or should some
> other approach be used to achieve our goal (authentication of the clients
> against 2 or more different authentication providers on one broker port)?
>
> Thank you very much in advance.
>
> Kind regards,
> Daniil Kirilyuk
>

Re: Does Qpid Java broker close connection upon channel exception as well as closing the channel?

[Rob Godfrey]

So, according to the 0-9-1 definition (
https://www.amqp.org/specification/0-9-1/amqp-org-download), 404 is
supposed to be a channel error - so RabbitMQ is likely more correct than
the Java Broker.  IIRC there were a whole boatload of issues with clients
(particularly the old JMS client) trying to handle channel level
exceptions, so the decision was made to just treat everything as a
connection level exception.  Others may have a more accurate/detailed
memory.

-- Rob

On Mon, 12 Jul 2021 at 14:31, Fraser Adams
 wrote:

> For context I'm working on a project that is primarily using the
> RabbitMQ broker and using the Pika Python client library. As the Qpid
> Java broker supports AMQP 0.9.1 too I figured I'd try to connect to that
> too to see if I could compare relative performance.
>
> I ran into a couple of issues, the first is that by default the Java
> broker doesn't support PLAIN authentication on insecure transports so I
> needed to mod the config.json to add
>
> "secureOnlyMechanisms" : [ ],
>
> to "authenticationproviders"
>
> I thought/hoped that'd be enough, but unfortunately things kept failing
> with a 504 error complaining about channel :2 not existing
>
>
> As it happens, what I'm actually doing during the startup of my
> application is to check if an exchange with the name of the specified
> destination exists.
>
> The way I do that is to do an exchange_declare with passive=True. Now I
> know that when an exception/error occurs (e.g. a 404 NOT_FOUND) if the
> exchange doesn't exist then the channel is closed by the broker. To
> cater for this I create a temporary channel (in this case it would be
> channel :2) and call the exchange_declare passive=True using that
> channel and I get a pika.exceptions.ChannelClosedByBroker, which is what
> I'd expect.
>
> So that's how it is with RabbitMQ broker, but with Qpid Java subsequent
> things were failing and I narrowed it down to the connection having been
> closed in addition to the channel.
>
> I've tried creating an additional temporary *connection* in addition to
> the temporary channel that I was previously creating in order to run the
> passive=True exchange_declare and doing that seems to "work" in terms of
> the rest of the application now seems to carry on correctly.
>
>
> So really I'm curious, is the Qpid Java broker closing the connection in
> addition to closing the channel the expected behaviour in this scenario?
> It is certainly different compared with what RabbitMQ does, but I have
> no idea what the "correct" behaviour is in this circumstance.
>
> MTIA
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Outreachy Intern

[Rob Godfrey]

On Wed, 26 May 2021 at 11:29, Robbie Gemmell 
wrote:

> Welcome, Rakhi!
>
>
+1 - Welcome Rakhi!  Great to have you onboard.

-- Rob


> On Tue, 25 May 2021 at 18:28, Rakhi Kumari  wrote:
> >
> > Hi everyone!
> >
> > I am Rakhi Kumari from India. I’ll be contributing to Apache Qpid Proton
> as
> > an Outreachy intern for the next 3 months. More specifically, I’ll be
> > working on Implementing distributed tracing for Qpid Proton C++. My
> mentor
> > during my internship is Justin Ross.
> >
> > I started my open source journey a few months ago and it has been an
> > amazing experience.
> > Looking forward to learning more and grow with you all.
> >
> > Best regards,
> > Rakhi
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Message Persistence in Qpid Broker C++ (1.39)

[Rob Godfrey]

On Wed, 19 May 2021 at 17:04, Gordon Sim  wrote:

> On Wed, May 19, 2021 at 3:34 PM Namitha, Nancy  wrote:
> > Is Broker - J optimized for the below mentioned scenario.
>
> I believe the java broker will indeed perform better for synchronous
> publish. Best thing is to run a quick test though.
>

Broker-J does not rely on a flush timer, instead simply combining all DB
interactions that are running concurrently into a single write... So,
theoretically, for this particular case you shouldn't see the same sort of
latency... but as Gordon says you should really test with something that
best represents your actual expected workload.  In general if you care
about performance then sending individual messages synchronously is not a
good choice.

-- Rob

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

Re: [RABBITMQ/QPID-JMS/VHOST] failed to connect to a virtual host

[Rob Godfrey]

So, the Qpid JMS client only speaks AMQP 1.0.

In the past we released a different JMS client which spoke AMQP 0-9-1, and
AMQP 0-10.  I believe that last release of that is detailed here:
https://qpid.apache.org/releases/qpid-java-6.1.7/index.html

Just to forewarn - I believe there are a few issues where RabbitMQ either
chose to deviate from the AMQP specification, or the Qpid client
implementation expects behaviour that is not defined in AMQP 0-9-1 itself.
I know there have been people using this client against RabbitMQ in the
past with some success though.

-- Rob

Hope this helps,
Rob

On Fri, 12 Feb 2021 at 18:03, KOELMAN Herbert <
herbert.koel...@soprasteria.com> wrote:

> Got your point.
>
> If I understand this well, if I force QPID to use AMQP 0-9-1 than it might
> work. Am I assuming well :-)
>
> Is there a way to have QPID explicitly use AMQP 0-9-1 ? Or do I need to
> downgrade QPID's version ?
>
> (By the way, your help is much appreciated ;-) )
> -----Message d'origine-
> De : Rob Godfrey 
> Envoyé : vendredi 12 février 2021 15:29
> À : users@qpid.apache.org
> Cc : VARSHNEY Prerna 
> Objet : Re: [RABBITMQ/QPID-JMS/VHOST] failed to connect to a virtual host
>
> So, I think what you are seeing here is essentially a bug in the RabbtMQ
> AMQP 1.0 plugin.  IIRC (and it's been a while) they incorrectly assume an
> equivalence between the notion of terminus durability in AMQP 1.0 and Queue
> durability in AMQP 0-9-1.
>
> The log message you see:
>
> 2021-02-12 14:50:48.451 [error] <0.21151.0> Channel error on connection
> <0.21128.0> (127.0.0.1:49982 -> 127.0.0.1:5672, vhost: '/', user:
> 'guest'), channel 2:
> operation queue.declare caused a channel exception precondition_failed:
> inequivalent arg 'durable' for queue 'vval' in vhost '/': received 'false'
> but current is 'true'
>
> is basically from their AMQP 0-9-1 engine and talking about a requirement
> in AMQP 0-9-1 that when asserting the existence of a queue you must
> correctly specify whether it is durable or not.  These concepts do not have
> an equivalent in AMQP 1.0.
>
>  (Terminus durability can be thought of as something like "durable
> subscriptions" in JMS...  A non-durable terminus (which is what the JMS
> client creates) does not imply that the queue it is linking to needs to be
> non-durable - JMS consumers are not normally durable subscriptions, so
> durability of the terminus is false).  We've let them know about this bug
> before, but they didn't seem to believe that fixing it was a priority at
> the time.
>
> -- Rob
>
> On Fri, 12 Feb 2021 at 15:05, KOELMAN Herbert <
> herbert.koel...@soprasteria.com> wrote:
>
> > I have tried this broker URL setting and it's not working. Can this be
> > a bug in version :
> > 
> > org.apache.qpid
> > qpid-jms-client
> > 0.55.0
> > 
> >
> > Java QPID connexion code: JmsConnectionFactory qpidFactory = new
> > org.apache.qpid.jms.JmsConnectionFactory("amqp://localhost:5672/amqp.v
> > host=test");
> >
> > Rabbit's log:
> > 2021-02-12 14:50:47.650 [info] <0.21096.0> accepting AMQP connection
> > <0.21096.0> (127.0.0.1:49982 -> 127.0.0.1:5672)
> > 2021-02-12 14:50:48.451 [error] <0.21151.0> Channel error on
> > connection <0.21128.0> (127.0.0.1:49982 -> 127.0.0.1:5672, vhost: '/',
> user:
> > 'guest'), channel 2:
> > operation queue.declare caused a channel exception precondition_failed:
> > inequivalent arg 'durable' for queue 'vval' in vhost '/': received
> 'false'
> > but current is 'true'
> > 2021-02-12 14:50:48.452 [warning] <0.21125.0> Closing session for
> > connection <0.21096.0>:
> > {'v1_0.error',{symbol,<<"amqp:precondition-failed">>},{utf8,<<"PRECOND
> > ITION_FAILED
> > - inequivalent arg 'durable' for queue 'vval' in vhost '/': received
> > 'false' but current is 'true'">>},undefined}
> > 2021-02-12 14:50:48.454 [info] <0.21159.0> Closing all channels from
> > connection '<<"127.0.0.1:49982 -> 127.0.0.1:5672">>' because it has
> > been closed
> >
> > Rabbit vhosts setup:
> > herbert@centos-001$ sudo rabbitmqctl list_vhosts Listing vhosts ...
> > name
> > /test
> > /
> >
> > herbert@centos-001$ sudo rabbitmqctl list_queues -p /test
> > Timeout: 60.0 seconds ...
> > Listing queues for vhost /test ...
> > namemessages
> > vval0
> > conf.r  0
> > conf.q  0
> >
> > -Message d'origine-
> &g

Re: [RABBITMQ/QPID-JMS/VHOST] failed to connect to a virtual host

[Rob Godfrey]

So, I think what you are seeing here is essentially a bug in the RabbtMQ
AMQP 1.0 plugin.  IIRC (and it's been a while) they incorrectly assume an
equivalence between the notion of terminus durability in AMQP 1.0 and Queue
durability in AMQP 0-9-1.

The log message you see:

2021-02-12 14:50:48.451 [error] <0.21151.0> Channel error on connection
<0.21128.0> (127.0.0.1:49982 -> 127.0.0.1:5672, vhost: '/', user: 'guest'),
channel 2:
operation queue.declare caused a channel exception precondition_failed:
inequivalent arg 'durable' for queue 'vval' in vhost '/': received 'false'
but current is 'true'

is basically from their AMQP 0-9-1 engine and talking about a requirement
in AMQP 0-9-1 that when asserting the existence of a queue you must
correctly specify whether it is durable or not.  These concepts do not have
an equivalent in AMQP 1.0.

 (Terminus durability can be thought of as something like "durable
subscriptions" in JMS...  A non-durable terminus (which is what the JMS
client creates) does not imply that the queue it is linking to needs to be
non-durable - JMS consumers are not normally durable subscriptions, so
durability of the terminus is false).  We've let them know about this bug
before, but they didn't seem to believe that fixing it was a priority at
the time.

-- Rob

On Fri, 12 Feb 2021 at 15:05, KOELMAN Herbert <
herbert.koel...@soprasteria.com> wrote:

> I have tried this broker URL setting and it's not working. Can this be a
> bug in version :
> 
> org.apache.qpid
> qpid-jms-client
> 0.55.0
> 
>
> Java QPID connexion code: JmsConnectionFactory qpidFactory = new
> org.apache.qpid.jms.JmsConnectionFactory("amqp://localhost:5672/amqp.vhost=test");
>
> Rabbit's log:
> 2021-02-12 14:50:47.650 [info] <0.21096.0> accepting AMQP connection
> <0.21096.0> (127.0.0.1:49982 -> 127.0.0.1:5672)
> 2021-02-12 14:50:48.451 [error] <0.21151.0> Channel error on connection
> <0.21128.0> (127.0.0.1:49982 -> 127.0.0.1:5672, vhost: '/', user:
> 'guest'), channel 2:
> operation queue.declare caused a channel exception precondition_failed:
> inequivalent arg 'durable' for queue 'vval' in vhost '/': received 'false'
> but current is 'true'
> 2021-02-12 14:50:48.452 [warning] <0.21125.0> Closing session for
> connection <0.21096.0>:
> {'v1_0.error',{symbol,<<"amqp:precondition-failed">>},{utf8,<<"PRECONDITION_FAILED
> - inequivalent arg 'durable' for queue 'vval' in vhost '/': received
> 'false' but current is 'true'">>},undefined}
> 2021-02-12 14:50:48.454 [info] <0.21159.0> Closing all channels from
> connection '<<"127.0.0.1:49982 -> 127.0.0.1:5672">>' because it has been
> closed
>
> Rabbit vhosts setup:
> herbert@centos-001$ sudo rabbitmqctl list_vhosts
> Listing vhosts ...
> name
> /test
> /
>
> herbert@centos-001$ sudo rabbitmqctl list_queues -p /test
> Timeout: 60.0 seconds ...
> Listing queues for vhost /test ...
> namemessages
> vval0
> conf.r  0
> conf.q  0
>
> -Message d'origine-
> De : Rob Godfrey 
> Envoyé : jeudi 11 février 2021 15:16
> À : users@qpid.apache.org
> Cc : VARSHNEY Prerna 
> Objet : Re: [RABBITMQ/QPID-JMS/VHOST] failed to connect to a virtual host
>
> So, as per the docs at
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fqpid.apache.org%2Freleases%2Fqpid-jms-0.56.0%2Fdocs%2Findex.html%23amqp-configuration-optionsdata=04%7C01%7Cherbert.koelman%40soprasteria.com%7Cc056a5d95054481f85d608d8ce979a28%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C637486497808701172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bvM2C1glFR29i8RSOpRY8AhvGaZ59uYpe6qN6jZmqto%3Dreserved=0
> the amqp vhost needs to be set via a URL option rather than putting the
> vhost in the path, so I'd assume something like
>
> amqp://localhost:5672?amqp.vhost=tst
>
> -- Rob
>
> On Thu, 11 Feb 2021 at 13:20, KOELMAN Herbert <
> herbert.koel...@soprasteria.com> wrote:
>
> > We are indeed using AMQP version 1.0.
> >
> > Plugin list:
> > Enabled plugin file: /etc/rabbitmq/enabled_plugins Enabled plugins:
> >
> >  * rabbitmq_web_stomp
> >  * rabbitmq_stomp
> >  * rabbitmq_amqp1_0
> >  * amqp10_common
> >  * rabbitmq_management
> >  * amqp_client
> >  * rabbitmq_web_dispatch
> >  * cowboy
> >  * cowlib
> >  * rabbitmq_management_agent
> >
> > List of enable listeners
> > * Interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and
> > AMQP 1.0
> >
> > I had the feeling that this w

Re: [RABBITMQ/QPID-JMS/VHOST] failed to connect to a virtual host

[Rob Godfrey]

So, as per the docs at
https://qpid.apache.org/releases/qpid-jms-0.56.0/docs/index.html#amqp-configuration-options
the amqp vhost needs to be set via a URL option rather than putting the
vhost in the path, so I'd assume something like

amqp://localhost:5672?amqp.vhost=tst

-- Rob

On Thu, 11 Feb 2021 at 13:20, KOELMAN Herbert <
herbert.koel...@soprasteria.com> wrote:

> We are indeed using AMQP version 1.0.
>
> Plugin list:
> Enabled plugin file: /etc/rabbitmq/enabled_plugins
> Enabled plugins:
>
>  * rabbitmq_web_stomp
>  * rabbitmq_stomp
>  * rabbitmq_amqp1_0
>  * amqp10_common
>  * rabbitmq_management
>  * amqp_client
>  * rabbitmq_web_dispatch
>  * cowboy
>  * cowlib
>  * rabbitmq_management_agent
>
> List of enable listeners
> * Interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and
> AMQP 1.0
>
> I had the feeling that this would pair up nicely. When I connect my
> program to the default virtual host (/), all running fine.
>
>
> -Message d'origine-
> De : Rob Godfrey 
> Envoyé : jeudi 11 février 2021 13:14
> À : users@qpid.apache.org
> Cc : VARSHNEY Prerna 
> Objet : Re: [RABBITMQ/QPID-JMS/VHOST] failed to connect to a virtual host
>
> Are you enabling AMQP 1.0 support on RabbitMQ via their plugin (RabbitMQ
> does not support AMQP 1.0 by default - see
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rabbitmq.com%2Fprotocols.htmldata=04%7C01%7Cherbert.koelman%40soprasteria.com%7C654da22bd5b74fd6b67e08d8ce868582%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C637486424449291445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9LepJFWwMHaaQgsyfGxE8HDVpWuvdh%2Fii0VDZW11g6I%3Dreserved=0).
> The Qpid JMS client uses AMQP
> 1.0 only.
>
> -- Rob
>
> On Thu, 11 Feb 2021 at 13:06, KOELMAN Herbert <
> herbert.koel...@soprasteria.com> wrote:
>
> > Hello,
> >
> > I'd like to connect to a RabbitMQ virtual host, but it's not quite
> > clear how I should setup my JMS connection.
> >
> > I'm using
> >
> > -  RabbiMQ version 3.8.9
> >
> > -  Qipid-jms : 0.55.0
> >
> > I thought it was just a matter of adding the virtual host name at the
> > end of the connection URL. But the magic didn't happen.
> >
> > To connect with virtual host tst, I use amqp://localhost:5672/tst.
> >
> > We are using this connection factory class
> > org.apache.qpid.jms.JmsConnectionFactory.
> >
> > Any idea ?
> >
> > Regards
> >
> > Herbert
> >
> > Il vaut mieux suivre le bon chemin en boitant que le mauvais d'un pas
> > ferme
> >
> > Saint Augustin
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: broker j REST API getMessageContent help

[Rob Godfrey]

Did you see any sort of Java stack trace in the logs corresponding to this
issue?  If so, can you paste the stack trace here?

Thanks,
Rob

On Wed, 10 Feb 2021 at 09:45, bltw15  wrote:

> I'm trying to retrieve message content from the queue, but can't seem to
> get
> it right. What is an example of using getMessageContent, and where can I
> find the messageId?
>
>
> http://localhost:8080/api/latest/queue/default/default/TempQueue148d546b-ee1d-4d6d-ba60-f5964f4a5aa2/getMessageContent?messageId=1
>
> return:
>   "errorMessage" : "Cannot parse body"
>
>
> http://localhost:8080/api/latest/queue/default/default/TempQueue148d546b-ee1d-4d6d-ba60-f5964f4a5aa2
> return:
> {
> "id": "e358e151-a8ec-48cc-a7b2-de33d67a0e0e",
> "name": "TempQueue148d546b-ee1d-4d6d-ba60-f5964f4a5aa2",
> "type": "standard",
>
> ...
>
>
>
>
> --
> 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
>
>

Re: [RABBITMQ/QPID-JMS/VHOST] failed to connect to a virtual host

[Rob Godfrey]

Are you enabling AMQP 1.0 support on RabbitMQ via their plugin (RabbitMQ
does not support AMQP 1.0 by default - see
https://www.rabbitmq.com/protocols.html).  The Qpid JMS client uses AMQP
1.0 only.

-- Rob

On Thu, 11 Feb 2021 at 13:06, KOELMAN Herbert <
herbert.koel...@soprasteria.com> wrote:

> Hello,
>
> I'd like to connect to a RabbitMQ virtual host, but it's not quite clear
> how I should setup my JMS connection.
>
> I'm using
>
> -  RabbiMQ version 3.8.9
>
> -  Qipid-jms : 0.55.0
>
> I thought it was just a matter of adding the virtual host name at the end
> of the connection URL. But the magic didn't happen.
>
> To connect with virtual host tst, I use amqp://localhost:5672/tst.
>
> We are using this connection factory class
> org.apache.qpid.jms.JmsConnectionFactory.
>
> Any idea ?
>
> Regards
>
> Herbert
>
> Il vaut mieux suivre le bon chemin en boitant que le mauvais d'un pas ferme
>
> Saint Augustin
>
>

Re: [VOTE] Release Qpid Broker-J 7.1.9

[Rob Godfrey]

+1

- built from source and ran tests
- kicked the tyres through the management console

On Thu, 17 Sep 2020 at 12:11, Gordon Sim  wrote:
>
> On 15/09/2020 12:55 am, Oleksandr Rudyy wrote:
> > Hi folks,
> >
> > I built release artefacts for Qpid Broker-J version 7.1.9 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.9-rc1/
> >
> > The maven artifacts are also staged at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1204
> >
> > 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=12347794
>
> +1
>
> - verified signature and checksum
> - built source and ran tests (had to exclude SpnegoAuthenticatorTest and
>InMemoryDatabaseTestBase due to errors believed to be environmental
>also skipped MalformedMessage
>publishMalformedMessageInTransactionExceedingMaxUncommittedLimit as
>that was failing)
> - ran qpid::messaging client against it for 0-10 and 1.0
> - ran proton python 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 Qpid Broker-J 8.0.1

[Rob Godfrey]

+1

- built from source and ran tests
- kicked the tyres through the management console

On Thu, 17 Sep 2020 at 11:45, Gordon Sim  wrote:
>
> On 15/09/2020 1:37 am, Oleksandr Rudyy wrote:
> > Hi guys,
> >
> > I built release artefacts for Qpid Broker-J version 8.0.1 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/8.0.1-rc1/
> >
> > The maven artifacts are also staged at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1205/
> >
> > 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=12347793
>
> +1
>
> - verified signature and checksum
> - built source and ran tests (had to exclude SpnegoAuthenticatorTest and
>InMemoryDatabaseTestBase dues to errors believed to be environmental)
> - ran qpid::messaging client against it for 0-10 and 1.0
> - ran proton python 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: qpid-jms-client

[Rob Godfrey]

On Tue, 11 Aug 2020 at 13:13, AnujaAlli  wrote:
>
> Hi Team,
>
> Currently we are using *qpid-amqp-1-0-client-jms(0.27) * version, we want to
> upgrade that to newer version.
> We found that there is no new version introduced after 0.32 which contains
> deadlock issue (https://issues.apache.org/jira/browse/QPID-6447).
>
> Just wanted to confirm new *qpid-jms-client* which is at
> https://qpid.apache.org/components/jms/ location solves deadlock problem
> which were introduced in qpid-amqp-1-0-client-jms(0.32) version?
>


The qpid-jms-client uses a completely different codebase, and so would
not be affected by the bug you referenced.

> Can you please guide me regarding the same or suggest any other library
> which gives same functionality?

The Qpid JMS client library is the client we recommend for using JMS
with AMQP 1.0

-- Rob

>
>
>
>
>
>
> --
> 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: Broker-J: Message larger than 2GB

[Rob Godfrey]

I think it's quite likely that there is a limitation somewhere where
int is used (or possibly just an array created) which means that 2Gb
is the effective message size limit.  Do you actually have a
requirement for such an enormously sized message - or are you just
testing?

-- Rob

On Thu, 9 Jul 2020 at 13:44, Tomas Soltys  wrote:
>
> Hi,
>
> I set qpid.max_message_size to -1 (unlimited) and tried to send some large
> messages. I noticed that once I get beyond 2GB I'm not able to send
> anything. Sender just hangs. And there is no error nor anything interesting
> in broker log as well.
>
> I tried with this command:
>
>
>
> Is there a hard limit 2GB?
>
> Thanks and 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: [VOTE] Release Apache Qpid JMS 0.50.0

[Rob Godfrey]

+1

Built from source and ran tests
Ran Qpid Broker-J systests using built JMS client


-- Rob


On Wed, 11 Mar 2020 at 19:22, Timothy Bish  wrote:

> On 3/11/20 12:35 PM, Robbie Gemmell wrote:
> > Hi folks,
> >
> > I have put together a spin for a 0.50.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.50.0-rc1/
> >
> > The maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1193
> >
> > The JIRAs assigned are:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314524=12347029
> >
> > 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-1193
> 
> >  
> >
> >
> > The dependency for the client itself would then be:
> >
> >
> >  org.apache.qpid
> >  qpid-jms-client
> >  0.50.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
> * Verified License and Notice files present
> * Check source license header using 'mvn apache-rat:check'
> * Built from source and ran all tests
> * Built ActiveMQ 5.x master and ran AMQP tests
> * Built ActiveMQ Artemis master and ran AMQP integration tests
>
>
> --
> Tim Bish
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Broker-J] Claim-check pattern and MessageDeleteListener

[Rob Godfrey]

So - the more I think about this, the more I think a custom store might be
the best way to approach this. For safety I think the approach I would take
is that on asking for the message to be removed from the DB, I would write
the blob id into a separate table (in the same transaction as the delete).
Then we can have a separate thread that is iterating over the table of
"blobs to be deleted", and for every row it finds it can call the blob
store to delete, and only remove the row from the "blobs to be deleted"
table when it gets confirmation that the blob has, indeed, been removed
from the external store.  In this way we can separate the deletion of the
message data from interaction with the external blob store (so, e.g. if the
blob store is unreachable it doesn't delay anything else), and on restart
the store can just start deleting the blobs by id of anything that is left
in the table.

-- Rob

On Wed, 11 Mar 2020 at 10:33, VERMEULEN Olivier 
wrote:

> from many queues on the same broker
> ____________
> From: Rob Godfrey 
> Sent: Wednesday, March 11, 2020 10:01:43 AM
> To: users@qpid.apache.org 
> Subject: Re: [Broker-J] Claim-check pattern and MessageDeleteListener
>
> On Wed, 11 Mar 2020 at 09:46, VERMEULEN Olivier <
> olivier.vermeu...@murex.com>
> wrote:
>
> > Why don't we just trigger the existing MessageDeleteListeners at the
> > beginning of the remove method instead of doing it at the end ?
> >
> >
> https://github.com/apache/qpid-broker-j/blob/master/broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/AbstractJDBCMessageStore.java#L1670
> >
> >
> https://github.com/apache/qpid-broker-j/blob/master/bdbstore/src/main/java/org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java#L1199
> >
> > This way we handle both the normal use case and the recovery one and the
> > headers will still be accessible from the StoredMessage instance (need to
> > add a getter in StorableMessageMetaData).
> > I can provide a pull-request if you want.
> >
>
> I still don't think this will work well for getting the header data - you
> really need to be operating on the AbstractServerMessage not the
> StoredMessage if you want to access the (protocol dependent implementation)
> headers / content.
>
> I think the current approach (and others that I have briefly thought about)
> will also fall down in the case of "orphaned" content bodies that are being
> deleted on broker restart (basically because the delete of the content -
> deliberately - not in a transaction with the delete of the per-queue
> enqueue records, an abrupt shutdown of the broker can leave message data in
> the store which is no longer referenced by any queues.  In this case the
> recovery code identifies the orphans and deletes them - but this is a
> database level operation rather than on the message model - and you can't
> assume the headers will be available there either (they are stored in a
> separate table).
>
> In a previous mail, you talked about "multicast" - is the expectation that
> the underlying blob may be being referenced from many queues on the same
> broker? or on queues on many different brokers?
>
> -- Rob
>
>
> >
> > WDYT?
> > Olivier
> >
> > From: VERMEULEN Olivier 
> > Sent: mardi 10 mars 2020 20:08
> > To: users@qpid.apache.org
> > Subject: Re: [Broker-J] Claim-check pattern and MessageDeleteListener
> >
> > The idea is to avoid any performance impact on the messaging when big
> > messages arrive.
> > So whenever a producer tries to send a big message (more than 10KB for
> us)
> > we put the payload in the blob store with a unique ID and we pass this ID
> > in the message instead of the original payload.
> > When a consumer receives such a message we then retrieve the payload from
> > the blob store.
> > The problem is that we can't expect the consumer to handle the cleanup of
> > the blob store since it might not be the only consumer receiving this
> > message (multicast for example or even a message being routed to 2 queues
> > through a topic).
> > The only one that really knows when the payload can be removed from the
> > blob store is the broker.
> > That's why I was looking for a hook that would be called whenever a
> > message is or will be deleted from the store (this includes the recovery
> > process).
> > After that whether the hook is at the queue or virtual host level doesn't
> > really matter...
> >
> > Olivier
> > 
> > From: Rob Godfrey  rob.j.godf...@gmail.com
> > >>
> > Sent: Tuesday, March 10, 2020

Re: [VOTE] Release Qpid Broker-J 8.0.0

[Rob Godfrey]

On Tue, 10 Mar 2020 at 18:09, Gordon Sim  wrote:

> On 10/03/2020 4:45 pm, Gordon Sim wrote:
> > On 04/03/2020 11:44 am, Alex Rudyy wrote:
> >> Hi all,
> >>
> >> I built release artefacts for Qpid Broker-J version 8.0.0 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/8.0.0-rc1/
> >>
> >> The maven artifacts are also staged at:
> >> https://repository.apache.org/content/repositories/orgapacheqpid-1192
> >>
> >> The new version brings a number of improvements and bug fixes
> >> including changes to ACL to limit the number of connections per user
> >> and support for trusted CA revocation list.
> >>
> >> You can find the full list of JIRAs included into the release here:
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12344778
> >>
> >
> > Verified signature and checksum, built from source, ran tests (see
> > below) and ran c++ qpid::messaging and python proton examples against it
> > without issue.
>
> To be explicit, I am +1 on the release and only mention the issues below
> in passing.
>

+1 from me
Built from source, ran 1.0 and 0-9-1 tests
Used the management console for a bit of ad-hoc testing

-- Rob


>
>
> > However I did get a few errors running the tests. As well as the
> > kerberos related ones mentioned for previous releases, which are somehow
> > a result of my environment, this time I got:
> >
> >> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> >> elapsed: 0.004 s <<< FAILURE! - in
> >> org.apache.qpid.server.logging.logback.jdbc.InMemoryDatabaseTestBase
> >> [ERROR]
> >>
> initializationError(org.apache.qpid.server.logging.logback.jdbc.InMemoryDatabaseTestBase)
>
> >> Time elapsed: 0.004 s  <<< ERROR!
> >> org.junit.runners.model.InvalidTestClassError: Invalid test class
> >> 'org.apache.qpid.server.logging.logback.jdbc.InMemoryDatabaseTestBase':
> >>   1. No runnable methods
> >
> > and:
> >
> >> [ERROR] Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time
> >> elapsed: 1.028 s <<< FAILURE! - in
> >> org.apache.qpid.tests.protocol.v0_8.extension.basic.MalformedMessage
> >> [ERROR]
> >>
> publishMalformedMessageInTransactionExceedingMaxUncommittedLimit(org.apache.qpid.tests.protocol.v0_8.extension.basic.MalformedMessage)
>
> >> Time elapsed: 0.017 s  <<< ERROR!
> >> java.lang.IllegalStateException: Unexpected response. Expected
> >> 'ChannelClosedResponse' got '[TxCommitOkBody]'.
> >> at
> >>
> org.apache.qpid.tests.protocol.v0_8.extension.basic.MalformedMessage.publishMalformedMessageInTransactionExceedingMaxUncommittedLimit(MalformedMessage.java:154)
>
> >>
> >
> > These may again be environmental.
> >
> >
> > -
> > 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] Claim-check pattern and MessageDeleteListener

[Rob Godfrey]

On Wed, 11 Mar 2020 at 09:46, VERMEULEN Olivier 
wrote:

> Why don't we just trigger the existing MessageDeleteListeners at the
> beginning of the remove method instead of doing it at the end ?
>
> https://github.com/apache/qpid-broker-j/blob/master/broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/AbstractJDBCMessageStore.java#L1670
>
> https://github.com/apache/qpid-broker-j/blob/master/bdbstore/src/main/java/org/apache/qpid/server/store/berkeleydb/AbstractBDBMessageStore.java#L1199
>
> This way we handle both the normal use case and the recovery one and the
> headers will still be accessible from the StoredMessage instance (need to
> add a getter in StorableMessageMetaData).
> I can provide a pull-request if you want.
>

I still don't think this will work well for getting the header data - you
really need to be operating on the AbstractServerMessage not the
StoredMessage if you want to access the (protocol dependent implementation)
headers / content.

I think the current approach (and others that I have briefly thought about)
will also fall down in the case of "orphaned" content bodies that are being
deleted on broker restart (basically because the delete of the content -
deliberately - not in a transaction with the delete of the per-queue
enqueue records, an abrupt shutdown of the broker can leave message data in
the store which is no longer referenced by any queues.  In this case the
recovery code identifies the orphans and deletes them - but this is a
database level operation rather than on the message model - and you can't
assume the headers will be available there either (they are stored in a
separate table).

In a previous mail, you talked about "multicast" - is the expectation that
the underlying blob may be being referenced from many queues on the same
broker? or on queues on many different brokers?

-- Rob


>
> WDYT?
> Olivier
>
> From: VERMEULEN Olivier 
> Sent: mardi 10 mars 2020 20:08
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] Claim-check pattern and MessageDeleteListener
>
> The idea is to avoid any performance impact on the messaging when big
> messages arrive.
> So whenever a producer tries to send a big message (more than 10KB for us)
> we put the payload in the blob store with a unique ID and we pass this ID
> in the message instead of the original payload.
> When a consumer receives such a message we then retrieve the payload from
> the blob store.
> The problem is that we can't expect the consumer to handle the cleanup of
> the blob store since it might not be the only consumer receiving this
> message (multicast for example or even a message being routed to 2 queues
> through a topic).
> The only one that really knows when the payload can be removed from the
> blob store is the broker.
> That's why I was looking for a hook that would be called whenever a
> message is or will be deleted from the store (this includes the recovery
> process).
> After that whether the hook is at the queue or virtual host level doesn't
> really matter...
>
> Olivier
> 
> From: Rob Godfrey mailto:rob.j.godf...@gmail.com
> >>
> Sent: Tuesday, March 10, 2020 6:26:39 PM
> To: users@qpid.apache.org<mailto:users@qpid.apache.org> <
> users@qpid.apache.org<mailto:users@qpid.apache.org>>
> Subject: Re: [Broker-J] Claim-check pattern and MessageDeleteListener
>
> Yeah - I was wondering if it might be better to add hooks into the point at
> which remove() is called (i.e.
>
> https://github.com/apache/qpid-broker-j/blob/master/broker-core/src/main/java/org/apache/qpid/server/message/AbstractServerMessageImpl.java#L127
> ),
> because a listener on the here could actually work with the message object
> where the headers are available... However this would miss the other point
> at which messages are removed from the store - in the store recovery
> process (e.g.
>
> https://github.com/apache/qpid-broker-j/blob/master/broker-core/src/main/java/org/apache/qpid/server/virtualhost/AsynchronousMessageStoreRecoverer.java#L227
> ).
> Unfortunately at this point we wouldn't have access to the headers.
>
> Can you explain a bit more how your blob storage is supposed to work.
> Perhaps there is another way that we can add a hook that would help here
> (e.g. on a per queue basis have some sort of "dequeue" trigger which is
> passed the message it is about to be permanently removed from the queue).
>
> -- Rob
>
> On Tue, 10 Mar 2020 at 17:59, VERMEULEN Olivier <
> olivier.vermeu...@murex.com<mailto:olivier.vermeu...@murex.com>>
> wrote:
>
> > The cast works fine in my case but the problem is that everything is
> NULL,
> > including the meta-data.
> > Indeed 

Re: [Broker-J] Claim-check pattern and MessageDeleteListener

[Rob Godfrey]

Yeah - I was wondering if it might be better to add hooks into the point at
which remove() is called (i.e.
https://github.com/apache/qpid-broker-j/blob/master/broker-core/src/main/java/org/apache/qpid/server/message/AbstractServerMessageImpl.java#L127
),
because a listener on the here could actually work with the message object
where the headers are available... However this would miss the other point
at which messages are removed from the store - in the store recovery
process (e.g.
https://github.com/apache/qpid-broker-j/blob/master/broker-core/src/main/java/org/apache/qpid/server/virtualhost/AsynchronousMessageStoreRecoverer.java#L227
).
Unfortunately at this point we wouldn't have access to the headers.

Can you explain a bit more how your blob storage is supposed to work.
Perhaps there is another way that we can add a hook that would help here
(e.g. on a per queue basis have some sort of "dequeue" trigger which is
passed the message it is about to be permanently removed from the queue).

-- Rob

On Tue, 10 Mar 2020 at 17:59, VERMEULEN Olivier 
wrote:

> The cast works fine in my case but the problem is that everything is NULL,
> including the meta-data.
> Indeed the message is cleaned before the listeners are called...
>
> https://github.com/apache/qpid-broker-j/blob/7193e26f6fad83f5ce81fd9ef855edb0fd5594ea/broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/AbstractJDBCMessageStore.java#L1670
>
> Olivier
>
> -----Original Message-
> From: Rob Godfrey 
> Sent: lundi 9 mars 2020 09:58
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] Claim-check pattern and MessageDeleteListener
>
> On Mon, 9 Mar 2020 at 09:36, VERMEULEN Olivier <
> olivier.vermeu...@murex.com>
> wrote:
>
> > Hello Rob,
> >
> > "Are you looking to have Broker-J trigger the deletion on the blob at
> > the point at which it believes it no longer needs the message?"
> > Yes that's exactly what I'm trying to do.
> > Note that I managed to do it by creating my own vhost, just wanted to
> > check if there was a less intrusive way of doing it...
> > I agree that we shouldn't be able to modify the message but today I
> > can't even read it easily.
> > What I'm interested in are the headers but from a StoredMessage
> > instance I have to go through internal classes and package-protected
> > classes to get
> > them:
> > ((InternalMessageMetaData) storedMessage.getMetaData()).getHeader();
> > getHeader being package-protected here...
> >
>
> Note that this will only work if the message is an "Internal" message (i.e.
> the casting here would fail if the message were an AMQP 0-9, AMQP 0-10 or
> AMQP 1.0 message sent over the wire).  The store API is basically built to
> be as unaware of the form of the message as possible, and the api here is
> basically designed to allow the store to clean up a message which was
> potentially stored in multiple queues, but which has now been removed from
> all of them.  As such it's not really designed to make it easy for you to
> access the headers (or content - since the "content" will include structure
> for 1.0 messages).
>
>
> > Did I miss something?
> >
>
> No - I think to do this safely we'd have to expose some new API here.
>
> -- Rob
>
>
> >
> > Thanks,
> > Olivier
> >
> > -Original Message-
> > From: Rob Godfrey 
> > Sent: vendredi 6 mars 2020 17:54
> > To: users@qpid.apache.org
> > Subject: Re: [Broker-J] Claim-check pattern and MessageDeleteListener
> >
> > Hi Olivier
> >
> > I'm not entirely sure what your exact idea here is - are you looking
> > to have Broker-J trigger the deletion on the blob at the point at
> > which it believes it no longer needs the message?  Or maybe to update
> > the blob store to make clear that the broker no longer needs to retain
> > a copy of the message?
> >
> > Clearly the API is not designed for allowing extensions here - and I
> > think if we were to try to make it an extension / interception point
> > then we would have to be careful in limiting what could be done here
> > (e.g. offering only some read-only view of the message).
> >
> > Without such an interception extension mechanism, you are correct I
> > think that you would need to create a new vhost type (potentially
> > using a new store type of your own implementation)
> >
> > -- Rob
> >
> > On Fri, 6 Mar 2020 at 16:37, VERMEULEN Olivier <
> > olivier.vermeu...@murex.com>
> > wrote:
> >
> > > Hello,
> > >
> > > We're trying to implement the claim-check pattern on top of our
> > &g

Re: [Broker-J] Claim-check pattern and MessageDeleteListener

[Rob Godfrey]

On Mon, 9 Mar 2020 at 09:36, VERMEULEN Olivier 
wrote:

> Hello Rob,
>
> "Are you looking to have Broker-J trigger the deletion on the blob at the
> point at which it believes it no longer needs the message?"
> Yes that's exactly what I'm trying to do.
> Note that I managed to do it by creating my own vhost, just wanted to
> check if there was a less intrusive way of doing it...
> I agree that we shouldn't be able to modify the message but today I can't
> even read it easily.
> What I'm interested in are the headers but from a StoredMessage instance I
> have to go through internal classes and package-protected classes to get
> them:
> ((InternalMessageMetaData) storedMessage.getMetaData()).getHeader();
> getHeader being package-protected here...
>

Note that this will only work if the message is an "Internal" message (i.e.
the casting here would fail if the message were an AMQP 0-9, AMQP 0-10 or
AMQP 1.0 message sent over the wire).  The store API is basically built to
be as unaware of the form of the message as possible, and the api here is
basically designed to allow the store to clean up a message which was
potentially stored in multiple queues, but which has now been removed from
all of them.  As such it's not really designed to make it easy for you to
access the headers (or content - since the "content" will include structure
for 1.0 messages).


> Did I miss something?
>

No - I think to do this safely we'd have to expose some new API here.

-- Rob


>
> Thanks,
> Olivier
>
> -Original Message-
> From: Rob Godfrey 
> Sent: vendredi 6 mars 2020 17:54
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] Claim-check pattern and MessageDeleteListener
>
> Hi Olivier
>
> I'm not entirely sure what your exact idea here is - are you looking to
> have Broker-J trigger the deletion on the blob at the point at which it
> believes it no longer needs the message?  Or maybe to update the blob store
> to make clear that the broker no longer needs to retain a copy of the
> message?
>
> Clearly the API is not designed for allowing extensions here - and I think
> if we were to try to make it an extension / interception point then we
> would have to be careful in limiting what could be done here (e.g. offering
> only some read-only view of the message).
>
> Without such an interception extension mechanism, you are correct I think
> that you would need to create a new vhost type (potentially using a new
> store type of your own implementation)
>
> -- Rob
>
> On Fri, 6 Mar 2020 at 16:37, VERMEULEN Olivier <
> olivier.vermeu...@murex.com>
> wrote:
>
> > Hello,
> >
> > We're trying to implement the claim-check pattern on top of our broker
> > + dispatch-router topology.
> > So we have a blob store and the idea is for each message above 10KB to
> > store the payload in it and to only keep an ID in the message.
> > The tricky part is the delete of the payload in the blob store,
> > especially since some of our use cases are using multicast...
> > When looking at the Broker-J source code I found this
> > MessageDeleteListener which would be really helpful for this use case:
> >
> > https://github.com/apache/qpid-broker-j/blob/c018e1ac9d21e9f5eb38d2ae7
> > a26a31e63c07fdf/broker-core/src/main/java/org/apache/qpid/server/store
> > /MessageStore.java#L84
> >
> > My first question would be, is it ok to use it?
> > Second, so far the only way I found to register a new listener is to
> > define my own VirtualHost, is there an easier way ?
> >
> > 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
>
>

Re: C++ Broker

[Rob Godfrey]

On Sat, 7 Mar 2020 at 04:16, Virgilio Fornazin 
wrote:

> RHEL is pushing Dispatcher + Broker-J (Artemis based) as the new A-MQ
> solution.
>

Just to be clear Artemis is part of the ActiveMQ project and not related to
Qpid Broker-J

-- Rob


> With container and another new things happening, could be the new way.
> But C++ broker still the fastest and best broker around for me
>
> On Fri, Mar 6, 2020 at 1:33 PM Robbie Gemmell 
> wrote:
>
> > The C++ broker sees occasional bug fixes (some are probably overdue a
> > release currently, its been a while), but there isnt active feature
> > development around it.
> >
> > On Fri, 6 Mar 2020 at 15:39, Bruce Parr  wrote:
> > >
> > > Hello,
> > >
> > > Is the C++ broker still under development/maintenance, or should we
> > start thinking about switching to Broker-J?
> > >
> > > Thanks,
> > > Bruce
> > >
> > >
> > >
> > > -
> > > 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] Claim-check pattern and MessageDeleteListener

[Rob Godfrey]

Hi Olivier

I'm not entirely sure what your exact idea here is - are you looking to
have Broker-J trigger the deletion on the blob at the point at which it
believes it no longer needs the message?  Or maybe to update the blob store
to make clear that the broker no longer needs to retain a copy of the
message?

Clearly the API is not designed for allowing extensions here - and I think
if we were to try to make it an extension / interception point then we
would have to be careful in limiting what could be done here (e.g. offering
only some read-only view of the message).

Without such an interception extension mechanism, you are correct I think
that you would need to create a new vhost type (potentially using a new
store type of your own implementation)

-- Rob

On Fri, 6 Mar 2020 at 16:37, VERMEULEN Olivier 
wrote:

> Hello,
>
> We're trying to implement the claim-check pattern on top of our broker +
> dispatch-router topology.
> So we have a blob store and the idea is for each message above 10KB to
> store the payload in it and to only keep an ID in the message.
> The tricky part is the delete of the payload in the blob store, especially
> since some of our use cases are using multicast...
> When looking at the Broker-J source code I found this
> MessageDeleteListener which would be really helpful for this use case:
>
> https://github.com/apache/qpid-broker-j/blob/c018e1ac9d21e9f5eb38d2ae7a26a31e63c07fdf/broker-core/src/main/java/org/apache/qpid/server/store/MessageStore.java#L84
>
> My first question would be, is it ok to use it?
> Second, so far the only way I found to register a new listener is to
> define my own VirtualHost, is there an easier way ?
>
> 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.
>

Re: [VOTE] Release Qpid Broker-J 7.1.8

[Rob Godfrey]

+1

built from source
ran 0-9-1 and 1.0 tests
started the broker and kicked the tyres of the management console

-- Rob

On Mon, 10 Feb 2020 at 12:12, Oleksandr Rudyy  wrote:

> +1
>
> My tests included the following:
> * verified signatures and checksums
> * built broker from source bundle and ran all tests
> * started broker and created queue via web management console
> * ran successfully hello world examples
>
>
> On Fri, 7 Feb 2020 at 16:33, Oleksandr Rudyy  wrote:
>
> > Hi folks,
> >
> > I built release artefacts for Qpid Broker-J version 7.1.8 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.8-rc1/
> >
> > The maven artifacts are also staged at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1190
> >
> > 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=12346892
> >
> > 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-1190
> > 
> > 
> > 
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
>

Re: An imperative AMQP client API

[Rob Godfrey]

On Tue, 28 Jan 2020 at 22:35, Alan Conway  wrote:

> On Mon, Jan 27, 2020 at 7:44 AM Justin Ross  wrote:
>
> > I like to think of the message as a pure value object.  As a result, it
> can
> > have whatever lifecycle the API user chooses.  For me, that's a reason to
> > isolate it from the delivery and tracker, because they do have more
> tightly
> > defined lifecycles.
> >
> > If there was a substantial win in convenience, I wouldn't be too bothered
> > to have them combined, but in practice, I don't think it does make a big
> > difference in convenience terms.  For me, the separation of concerns is a
> > bigger win.
> >
>
> Big +1 - you don't acknowledge a message, you acknowledge a delivery. It's
> important because messages aren't just received, they also be sent, copied,
> stored etc.
>

Hmmm  The message data (and maybe the application properties),
certainly.  The annotations may be more dubious.  Logically at the very
least the delivery-annotations are closer to the delivery than to you
abstract notion of message.  Moreover one might consider some aspects of
the message to be "owned" and set by the library... if, for instance, the
expectation is that the message-id is set by the library, what does it mean
when the "old" value is replaced by a different value on resending?

I do agree that there is a notion of "message" that has scope beyond the
delivery/sending of the message - but I'm not 100% convined that this is
1:1 with the representation of what is sent over the wire in AMQP as the
message.

-- Rob


> It is meaningless to "acknowledge" a message you just read from a database
> or took from an in-memory queue, or a new message you created in order to
> send it. So acknowledge is a method on a Delivery, not a Message. Same for
> trackers - they don't even exist until a message is sent, and they expire
> when the message is acknowledged,  data in the message can exist (or be
> destroyed) independently.
>
>
>
> > On Wed, Jan 22, 2020 at 6:04 AM Robbie Gemmell  >
> > wrote:
> >
> > > On Wed, 22 Jan 2020 at 09:39, Rob Godfrey 
> > wrote:
> > > >
> > > > On Tue, 21 Jan 2020 at 18:31, Robbie Gemmell <
> robbie.gemm...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > On Tue, 21 Jan 2020 at 17:06, Rob Godfrey  >
> > > wrote:
> > > > > >
> > > > > > On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell <
> > > robbie.gemm...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > On Tue, 21 Jan 2020 at 14:28, Rob Godfrey <
> > rob.j.godf...@gmail.com
> > > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell <
> > > > > robbie.gemm...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Tue, 21 Jan 2020 at 11:21, Rob Godfrey <
> > > rob.j.godf...@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > [... snip ...]
> > > > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > > 6. receiver-options - "auto-accept : Automatically accept
> > > > > deliveries
> > > > > > > that
> > > > > > > > > > are not explicitly acknowledged"... what does this mean -
> > > when
> > > > > does
> > > > > > > the
> > > > > > > > > > accept happen, when the message is initially received, or
> > > only
> > > > > if the
> > > > > > > > > > delivery somehow goes out of scope?
> > > > > > > > >
> > > > > > > > > For receive calls it would be when received.
> > > > > > > >
> > > > > > > >
> > > > > > > > If there was a listener
> > > > > > > > > (TBD) it would be after that returned. Much the same as
> > > existing
> > > > > > > > > clients auto ack essentially.
> > > > > > > > >
> > > > > > > >
> > > > > > > > So... looking through the API design... the only way I s

Re: [Broker-J] Add support for SQL Server to JDBC store

[Rob Godfrey]

Hi Olivier,

as long as there are no requirements for code with incompatible licenses to
be distributed by the Broker (which there shouldn't be) I don't see any
issues at all (basically this is the same as supporting one of the other
proprietary database vendors).
Given their common roots, I assume the SQL server configuration will be
mostly similar to the Sybase configuration (I think I may even have tested
this many many years ago).

-- Rob

On Wed, 29 Jan 2020 at 09:47, VERMEULEN Olivier 
wrote:

> Hello,
>
> We would like to contribute the support of SQL Server by the Broker-J JDBC
> store.
> But before doing the dev I just wanted to make sure that there is no
> restrictions on your side?
>
> 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.
>

Re: Certificate validation behavior changed in QPID Broker-J 7.1.5?

[Rob Godfrey]

I've created QPID-8404 for this and attached a very simple patch which I
hope should solve your issue

-- Rob


On Fri, 24 Jan 2020 at 10:43, Rob Godfrey  wrote:

> It looks like this might be related to changes made in the underlying
> Jetty library - https://github.com/eclipse/jetty.project/issues/3554
>
> It seems like a change needs to be made to Qpid Broker-J to explicitly
> disable this breaking change that Jetty introduced :-(
>
> -- Rob
>
> On Thu, 23 Jan 2020 at 21:48, David Gillingham - NOAA Affiliate
>  wrote:
>
>> I am attempting to upgrade a project currently running QPID Broker-J 7.1.0
>> to 7.1.7 and have discovered a change to the certificate validation
>> behavior that is breaking my application.
>> From what I've been able to figure out, it appears that starting with
>> release 7.1.5, when External Authentication is enabled, QPID now appears
>> to
>> attempt to match the hostname/IP address of any incoming connection to
>> either the subject or CN inside the client-provided certificate.
>> When attempting to make a REST API request using cURL on 7.1.5, I get the
>> following error:$ curl --cacert root.crt --cert guest.crt --key guest.key
>> https://dev25:8080/api/latest/queue
>> curl: (35) SSL peer had some unspecified issue with the certificate it
>> received.
>>
>> When I look at qpid.log, I found the following error:2020-01-23
>> 14:22:02,703 INFO  [qtp1186859375-45] (o.a.q.s.m.p.HttpManagement) - TLS
>> handshake failed: host='xxx.xxx.xxx.xxx', port=45572:
>> javax.net.ssl.SSLHandshakeException: No subject alternative names present
>> guest.crt/guest.key are an openssl generated cert/key pair adequate for
>> user authentication purposes. The subject/CN refer to my user.
>>
>> If I instead use the same cert/key pair that I've configured for the QPID
>> server, I can successfully get a response from the REST API. I assume this
>> is because that cert has my system's hostname in the subject/CN.
>>
>> I cannot reproduce these issues on release 7.1.4 or earlier.
>>
>> Can someone explain why this change to certificate validation behavior was
>> made and why it would be desirable? From my prior experience with
>> interacting with web applications that required certificates for
>> authentication, hostname checking was never part of the requirement. This
>> makes using new versions of QPID difficult as we'd have to generate a
>> large
>> number of new certificates for every host that connects to QPID instead of
>> letting users use their personal certificate.
>>
>

Re: Certificate validation behavior changed in QPID Broker-J 7.1.5?

[Rob Godfrey]

It looks like this might be related to changes made in the underlying Jetty
library - https://github.com/eclipse/jetty.project/issues/3554

It seems like a change needs to be made to Qpid Broker-J to explicitly
disable this breaking change that Jetty introduced :-(

-- Rob

On Thu, 23 Jan 2020 at 21:48, David Gillingham - NOAA Affiliate
 wrote:

> I am attempting to upgrade a project currently running QPID Broker-J 7.1.0
> to 7.1.7 and have discovered a change to the certificate validation
> behavior that is breaking my application.
> From what I've been able to figure out, it appears that starting with
> release 7.1.5, when External Authentication is enabled, QPID now appears to
> attempt to match the hostname/IP address of any incoming connection to
> either the subject or CN inside the client-provided certificate.
> When attempting to make a REST API request using cURL on 7.1.5, I get the
> following error:$ curl --cacert root.crt --cert guest.crt --key guest.key
> https://dev25:8080/api/latest/queue
> curl: (35) SSL peer had some unspecified issue with the certificate it
> received.
>
> When I look at qpid.log, I found the following error:2020-01-23
> 14:22:02,703 INFO  [qtp1186859375-45] (o.a.q.s.m.p.HttpManagement) - TLS
> handshake failed: host='xxx.xxx.xxx.xxx', port=45572:
> javax.net.ssl.SSLHandshakeException: No subject alternative names present
> guest.crt/guest.key are an openssl generated cert/key pair adequate for
> user authentication purposes. The subject/CN refer to my user.
>
> If I instead use the same cert/key pair that I've configured for the QPID
> server, I can successfully get a response from the REST API. I assume this
> is because that cert has my system's hostname in the subject/CN.
>
> I cannot reproduce these issues on release 7.1.4 or earlier.
>
> Can someone explain why this change to certificate validation behavior was
> made and why it would be desirable? From my prior experience with
> interacting with web applications that required certificates for
> authentication, hostname checking was never part of the requirement. This
> makes using new versions of QPID difficult as we'd have to generate a large
> number of new certificates for every host that connects to QPID instead of
> letting users use their personal certificate.
>

Re: An imperative AMQP client API

[Rob Godfrey]

On Tue, 21 Jan 2020 at 18:31, Robbie Gemmell 
wrote:

> On Tue, 21 Jan 2020 at 17:06, Rob Godfrey  wrote:
> >
> > On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell 
> > wrote:
> >
> > > On Tue, 21 Jan 2020 at 14:28, Rob Godfrey 
> wrote:
> > > >
> > > > On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell <
> robbie.gemm...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Tue, 21 Jan 2020 at 11:21, Rob Godfrey  >
> > > wrote:
> > > > > >
> > >
> > >
> > [... snip ...]
> >
> >
> > > > >
> > > > > > 6. receiver-options - "auto-accept : Automatically accept
> deliveries
> > > that
> > > > > > are not explicitly acknowledged"... what does this mean - when
> does
> > > the
> > > > > > accept happen, when the message is initially received, or only
> if the
> > > > > > delivery somehow goes out of scope?
> > > > >
> > > > > For receive calls it would be when received.
> > > >
> > > >
> > > > If there was a listener
> > > > > (TBD) it would be after that returned. Much the same as existing
> > > > > clients auto ack essentially.
> > > > >
> > > >
> > > > So... looking through the API design... the only way I see to
> receive a
> > > > message is through messaging-handler.on-message.  So the idea is the
> > > > auto-accept means that upon the return from on-message, if the
> outcome
> > > has
> > > > not been set to accepted, and the message has not already been
> settled
> > > (by
> > > > either side) then the outcome of the delivery will be set to
> accepted.
> > > >
> > >
> > > There are recieve calls on the reciever, see the bottom of
> > > https://www.ssorj.net/pumpjack/client/receiver/index.html.
> > >
> > >
> > How do you get from the delivery to the message?
> >
>
> In one case at least, currently delivery.message()
>

Looping back to Alex's question then - does the separation of delivery and
message actually save us anything in terms of being "lightweight" then, if
the delivery always needs to refer to the message?  I'm not intrinsically
against the separation, though in some ways it feels a bit odd to have
different object types for tracking inbound and outbound deliveries (the
tracker and delivery classes), but using a single type for both inbound and
outbound messages

-- Rob


>
> > With the recevier.receive call... I'm not sure how the second half of the
> > description "auto-accept : Automatically accept deliveries that are not
> > explicitly acknowledged" makes any sense.  I don't see how "explicitly
> > ackowledg[ing]" is even possible.
> >
>
> It isnt, calling receive with auto-accept would be expected to
> acknowledge immediately at present (unless some other behaviour were
> defined). The latter bit can only apply to the handler style usage.
>
> The text is loosely covering the bases, and was perhaps even copied
> from previous reactive api bits where auto-accept is an option and no
> receive style use is possible.
>
> > -- Rob
> >
> >
> >
> > > The messaging-handler stuff is again mostly part of the existing
> > > reactive bits (in some cases), which indeed work essentially as you
> > > describe. The idea would be something similar (but obviously narrower
> > > in operation scope) for the handler configurable in the reciever
> > > options.
> > >
> > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: An imperative AMQP client API

[Rob Godfrey]

On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell 
wrote:

> On Tue, 21 Jan 2020 at 14:28, Rob Godfrey  wrote:
> >
> > On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell 
> > wrote:
> >
> > > On Tue, 21 Jan 2020 at 11:21, Rob Godfrey 
> wrote:
> > > >
>
>
[... snip ...]


> > >
> > > > 6. receiver-options - "auto-accept : Automatically accept deliveries
> that
> > > > are not explicitly acknowledged"... what does this mean - when does
> the
> > > > accept happen, when the message is initially received, or only if the
> > > > delivery somehow goes out of scope?
> > >
> > > For receive calls it would be when received.
> >
> >
> > If there was a listener
> > > (TBD) it would be after that returned. Much the same as existing
> > > clients auto ack essentially.
> > >
> >
> > So... looking through the API design... the only way I see to receive a
> > message is through messaging-handler.on-message.  So the idea is the
> > auto-accept means that upon the return from on-message, if the outcome
> has
> > not been set to accepted, and the message has not already been settled
> (by
> > either side) then the outcome of the delivery will be set to accepted.
> >
>
> There are recieve calls on the reciever, see the bottom of
> https://www.ssorj.net/pumpjack/client/receiver/index.html.
>
>
How do you get from the delivery to the message?

With the recevier.receive call... I'm not sure how the second half of the
description "auto-accept : Automatically accept deliveries that are not
explicitly acknowledged" makes any sense.  I don't see how "explicitly
ackowledg[ing]" is even possible.

-- Rob



> The messaging-handler stuff is again mostly part of the existing
> reactive bits (in some cases), which indeed work essentially as you
> describe. The idea would be something similar (but obviously narrower
> in operation scope) for the handler configurable in the reciever
> options.
>
>

Re: An imperative AMQP client API

[Rob Godfrey]

On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell 
wrote:

> On Tue, 21 Jan 2020 at 11:21, Rob Godfrey  wrote:
> >
> > So... a few initial thoughts / queries from a brief look through.  I'll
> try
> > to do a more detailed review later
> >
> > 1. I don't see any mechanism for connection retry / alternate hosts in
> the
> > connect operation / connection-options parameter ; further I presume
> there
> > is no mechanism for attempted automated failover on connection error - is
> > this something that would be in a later scope?
>
> Areas still to look at, as Justin said towards the end of his mail
> this is early stuff and he specifically noted these bits as examples
> of outstanding areas.
>

fair - I'd bookmarked this as something to "review when I have 15 minutes
of spare time" - I didn't go back and check the other context in the mail
:-)


>
> > 2. In connection options
> >   i) it seems weird for virtual-host to be thought of as part of
> "identity"
> > when it is really an instruction about the remote server
>
>  Fair. I wouldnt read much into the grouping names on the page though,
> its the only place it occurs quite like that.
>

The other part to this is the various place that "host" can be provided -
SNI, Sasl and connection.open - not sure exactly how we want to open up all
those parts


>
> >  ii) The modelling of SASL is very tied to the "username/password" model.
> > Identity defines a "user" property - what does this represent if not part
> > of the SASL exchange? In the SASL section there is password section -
> which
> > only applies to traditional username/password mechanisms.  From a
> protocol
> > point of view the client gets to choose from the mechanisms offered by
> the
> > server, and the form of the credentials for each mechanism may differ.
> For
> > maximum flexibility I would think we would want something like a
> > credentials "bag", and an ordered list of mechanisms.  Each mechanism
> would
> > define what properties it needs to retrieve from the credentials bag
> (e.g.
> > an oauth token, or maybe a tls-client-certificate).
>
> I dont think having user/pass options for the basic simple case, still
> widely used, like all our existing clients do would prevent having
> other stuff for additional cases.
>
>
Yeah - it's more we shouldn't bake this as the *only* way.  A simplified
API for just username/password is fine, but I think the general case is
"bag of *stuff* for credentials"


> > iii) The tls options seem inadequate - how would the client express that
> it
> > wanted to send a particular client certificate, for instance, also which
> > certificates to trust (individual certs or CAs), CRLs, etc...
>
> I think that mainly a case of the page being incomplete, partly as we
> hadnt got there yet, and it being based on and relating to existing
> bits, e.g the C++ client it refers to, that such bits would likely
> build on existing bits.
>

I'm sort of seeing this as an opportunity to think how things should work
rather than solely being based on what's there already (which I believe has
gaps) :-)


>
> Certain code allows for configuring various such things via a set of
> connection ssl options currently.
>
> > iv) Given the very directional notion of TCP connections / SASL - I'm not
> > sure the same data structure should/can be used for both establishing
> > outgoing connections and incoming connections.  TLS (at least) would be
> > expected to treat "client" and "server" in the same sense as the TCP
> > connection I assume.  Would the same also be true of SASL?
>
> This is only to be client related.
>

OK - I was going by the (obviously very sketchy) container.listen which
also takes a connection-options parameter.  I think it needs to be clear at
the outset if we are looking at a API which aims to over both the connect /
accept case or just connect.


>
> > 3. I don't see a provision for using protocols other than AMQP directly
> > over TCP (e.g. how about websockets?)
>
> Early stuff, still stuff to consider. Certain code does allow for
> using websockets via a set of connection transport options currently.
>

Really just checking that this is in scope.


>
> > 4. After connection establishment, does the connection provide a way of
> > accessing information that was exchanged at the TLS or SASL layers
>
> Not yet, as many of the existing clients dont, and as ever just havent
> got to lots of things yet.
>
> > 5. In the connection object we have properties, offered-capabilities and
> > desired-capabilities - are

Re: An imperative AMQP client API

[Rob Godfrey]

So... a few initial thoughts / queries from a brief look through.  I'll try
to do a more detailed review later

1. I don't see any mechanism for connection retry / alternate hosts in the
connect operation / connection-options parameter ; further I presume there
is no mechanism for attempted automated failover on connection error - is
this something that would be in a later scope?
2. In connection options
  i) it seems weird for virtual-host to be thought of as part of "identity"
when it is really an instruction about the remote server
 ii) The modelling of SASL is very tied to the "username/password" model.
Identity defines a "user" property - what does this represent if not part
of the SASL exchange? In the SASL section there is password section - which
only applies to traditional username/password mechanisms.  From a protocol
point of view the client gets to choose from the mechanisms offered by the
server, and the form of the credentials for each mechanism may differ.  For
maximum flexibility I would think we would want something like a
credentials "bag", and an ordered list of mechanisms.  Each mechanism would
define what properties it needs to retrieve from the credentials bag (e.g.
an oauth token, or maybe a tls-client-certificate).
iii) The tls options seem inadequate - how would the client express that it
wanted to send a particular client certificate, for instance, also which
certificates to trust (individual certs or CAs), CRLs, etc...
iv) Given the very directional notion of TCP connections / SASL - I'm not
sure the same data structure should/can be used for both establishing
outgoing connections and incoming connections.  TLS (at least) would be
expected to treat "client" and "server" in the same sense as the TCP
connection I assume.  Would the same also be true of SASL?
3. I don't see a provision for using protocols other than AMQP directly
over TCP (e.g. how about websockets?)
4. After connection establishment, does the connection provide a way of
accessing information that was exchanged at the TLS or SASL layers
5. In the connection object we have properties, offered-capabilities and
desired-capabilities - are these referring to the values that were sent by
the client to the remote container or the values sent by the remote to the
client?  (Given the default value is "discovered I presume these are
supposed to be the values sent from the remote side, in which case the
description "Extensions the endpoint can use" is incorrect - they are
capabilities the remote side would like to use.  Similarly the virtual-host
and container-id - are these representing the virtual-host the remote
container desires to attach to, and the container-id by which the remote
side identifies itself?
6. receiver-options - "auto-accept : Automatically accept deliveries that
are not explicitly acknowledged"... what does this mean - when does the
accept happen, when the message is initially received, or only if the
delivery somehow goes out of scope?
7. receiver-options - how do auto-settle and delivery-mode interact?
8. There appears to be no way in delivery.reject to provide additional
information.  There also does not seem to be a way of setting the modified
outcome.  Also, is there a way for the client to be informed where the
remote side has spontaneously set the outcome?  The messaging handler only
seems to allow for being informed of outcome changes for sent messages (via
trackers) not received messages.

-- Rob



On Mon, 13 Jan 2020 at 13:40, Justin Ross  wrote:

> Hi, everyone.  For a while now, some members of the Qpid community have
> been working on a new style of messaging API.  It now has a reasonable
> shape, and we want to share it and get your feedback.
>
> We currently offer either JMS or Proton's reactive API.  These certainly
> aren't going anywhere - they're important - but for some use cases, the
> absence of a high-level command-oriented API for AMQP messaging is a source
> of inconvenience.
>
> This inconvenience comes in two forms.  First, JMS is helpfully imperative
> (in part - it contains multitudes), but it doesn't expose some of the
> things you can do with AMQP.  And it can't reasonably expose those things,
> because that would break the contract of the JMS API.  Second, the Proton
> APIs, since they are reactive, make it harder to handle cases where you
> need to sequence the processing of events.
>
> The imperative client API we are talking about here uses modern language
> support for futures or coroutines.  Most of the API's operation is
> asynchronous, but you can easily introduce blocking where you need to.
>
> It's a client API only.  We think a comparably high-level server API would
> be its own dedicated thing, functioning more like Python Flask or JAX-RS.
> In any case, the Proton reactive API is already a good fit for writing
> servers.
>
> We have the outline of the API and some proof-of-concept implementations,
> but much remains to be done.  We anticipate that this work 

Re: [VOTE] Release Qpid Broker-J 7.1.7

[Rob Godfrey]

+1

Built from source and ran 0-9-1 and 1-0 tests
started up the broker and kicked the tyres of the web ui

-- Rob

On Sun, 12 Jan 2020 at 23:14, Keith W  wrote:

> +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 Fri, 10 Jan 2020 at 15:16, Oleksandr Rudyy  wrote:
> >
> > +1
> >
> > * verified signatures and checksums
> > * built and ran tests from source bundle
> > * ran "hello world" example
> > * used web management console to create and bind queues
> >
> >
> > On Thu, 9 Jan 2020 at 17:00, Alex Rudyy  wrote:
> >
> > > Hi all,
> > >
> > > I built release artefacts for Qpid Broker-J version 7.1.7 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.7-rc1/
> > >
> > > The maven artifacts are also staged at:
> > > https://repository.apache.org/content/repositories/orgapacheqpid-1189
> > >
> > > 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=12346660
> > >
> > > 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-1189
> > > 
> > > 
> > > 
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > > For additional commands, e-mail: users-h...@qpid.apache.org
> > >
>

Re: [Qpid-Jms-Client] How does the broker get to know whether durable-shared-subscription should be associated with the containerId or not?

[Rob Godfrey]

I think all the details are in this JIRA:
https://issues.apache.org/jira/browse/QPIDJMS-220

-- Rob

On Thu, 9 Jan 2020 at 23:57, Neeraj Makam
 wrote:

> Hi
>
> Based on the spec of JMS 2.0, the clientId (which is set on the
> connection) is optional for shared durable subscription. And this was done
> so that multiple connections could talk to the same shared subscription.
> But in QPID JMS Client, I see that we are always setting a containerId
> (auto-generating one if doesn't exist), which in turn corresponds to
> clientId.
> At AMQP level, how do we distinguish between a containerId set
> automatically, v/s a client explicitly setting it?
>
> In short, How does the broker get to know whether
> durable-shared-subscription should be associated with the containerId or
> not?
>
> Thanks,
> Neeraj Makam
>

Re: Persistent messages in Durable Q not available after restart

[Rob Godfrey]

Hi Kristofor,

As Alex says, to me this looks like a problem with your environment
configuration / test set up - I cannot reproduce the issue you are seeing.

I downloaded Qpid 6.1.4, set up a virtual host as you described (JSON node,
BDB host) and a durable LVQ, with persist ALWAYS.  I sent a message, ran
qpid.stop and restarted the broker.  The message survived the broker
restart and was available for consumption.

-- Rob

On Thu, 19 Dec 2019 at 16:34, Oleksandr Rudyy  wrote:

> Hi Kristofor,
>
> The broker with provided virtual host and queue configuration should
> persist all published messages into message store and recover them on
> re-start.
> The fact that VirtualHost recovers all messages on its own re-start
> confirms the expected broker behaviour.
>
> It looks to me that you might have an issue with the storage. Could it be
> that the path to the message store changes between the restarts?
>
> Are you running Qpid broker in the container like docker?
>
> Kind Regards,
> Alex
>
>
>
>
> On Thu, 19 Dec 2019 at 14:46, Kristofor Horst 
> wrote:
>
> > Robbie Gemmell wrote
> > > It might help if you could provide a minimal reproducer
> >
> > I think this will do it - I can't copy from a file so I have to hand type
> > it
> > - apologies.
> >
> > *
> > {
> > "storepath":"path/to/qpid/etc/example/config",
> > "desiredState":"active",
> > "name":"example",
> > "context":{},
> > "modelVersion":"6.1",
> > "type":"BDB",
> > "exchanges":[{ "name":"amq.topic", "type":"topic",
> > "bindings":[{
> > "name": "PersistentLVQTester",
> > "type":"binding", "durable" :true,
> > "queue" : "PersistentLVQTester"
> > }]
> > }],
> > "queues":[{"messageGroupsSharedGroups":false,
> > "LVQKey":"PersistentLVQTopicKey",
> > "holdOnPublishEnabled":false,
> > "messageDurability":"ALWAYS",
> > "type":"lvq",
> > "durable":true,
> > "name":"PersistentLVQTester"
> > }]
> > }
> > *
> >
> >
> > Robbie Gemmell wrote
> > >  It might be worth trying newer versions for
> > > comparison too given there have been a number of releases since then.
> >
> > Unfortunately not an option for my use case. I am restricted to this
> > version, which is already a massive improvement from 0.20 that we were
> > using
> > before!
> >
> > I was able to make limited progress with messages persisting when the
> > virtualhost node of the broker is cycled via the UI. The message will
> > correctly reappear if the node is stopped and started through the
> > interface.
> > However, we'd like to be able to cycle the broker itself using the
> > qpid.stop
> > script file and have the messages persisted.
> >
> > Is this feasible or a misinterpretation of the system functionality?
> >
> >
> >
> >
> >
> > --
> > 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
> >
> >
>

Re: [VOTE] Release Qpid Broker-J 7.1.6

[Rob Godfrey]

+1 built from source, ran 0-9-1 and 1-0 tests, started up the broker and
kicked the tires.  Tested the new REST API parts on various JVMs (8, 11 ;
hotspot, J9) on my OS X machine.

-- Rob

On Mon, 2 Dec 2019 at 11:28, Alex Rudyy  wrote:

> Hi all,
>
> I built release artefacts for Qpid Broker-J version 7.1.6 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.6-rc1/
>
> The maven artifacts are also staged at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1186
>
> 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=12346457
>
> 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-1186
> 
> 
> 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

Re: Message timeouts before sending ack

[Rob Godfrey]

Hi Martin,

I'm pretty sure this is an Azure Service Bus "feature" rather than anything
on the client side.  I'm no expert on Service Bus, but I believe it grants
a "lock" on the message for the consumer to process it, and then revokes
the lock if processing has not completed within a timeout period.  I'm not
sure if this timeout can be changed (or the lock renewed in some way), but
if I am correct you'd be better off asking the Service Bus folks.

As an aside, for this sort of query it always helps if you can attach the
stack trace you receive from your client.  If you want to isolate whether
it is a client or server-side issue, you could try to replicate with a
different AMQP 1-0 server (such as Qpid Broker-J, or the Qpid C++ broker).

-- Rob

On Mon, 25 Nov 2019 at 17:42, Martín Paoloni
 wrote:

> Hi!
>
> I am using qpid-jms-client version 0.40.0 to connect to Azure Service Bus,
> but the same happens with the latest, 0.46.0. I'm having issues with the
> acknowledge process.
>
> My application receives a message from a queue or topic, and then processes
> it. It then does a manual ack.
> If this processing takes longer than 30 seconds, the acknowledge() call
> fails, and the message goes to the dead letter queue.
> If the processing takes less time (say, 20 seconds), then the ack works
> fine and the message is consumed.
>
> Here is a sample code that simulates this scenario, using
> Thread.sleep(3). Changing the value to 2 will make it work as
> expected.
> If you leave it at 3, the app gets no exception, and after a few
> retries, the number of messages in the queue stays the same, but the DLQ
> counter gets increased by one.
>
> package org.apache.qpid.jms.example;import
> org.apache.qpid.jms.JmsConnectionFactory;
> import org.apache.qpid.jms.JmsQueue;import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.ExceptionListener;
> import javax.jms.JMSException;
> import javax.jms.Message;
> import javax.jms.MessageConsumer;
> import javax.jms.Session;public class Receiver {private static
> String user = "user";
> private static String password = "password";
> private static String address =
> "amqps://test.servicebus.windows.net";public static void
> main(String[] args) throws Exception {
> try {
> ConnectionFactory factory = new JmsConnectionFactory(user,
> password, address);
> Connection connection = factory.createConnection(user,
> password);
> connection.setExceptionListener(new MyExceptionListener());
> connection.start();
> Session session = connection.createSession(false, 101);
> MessageConsumer messageConsumer =
> session.createConsumer(new JmsQueue("queue_test"));
> Message message = messageConsumer.receive();
> System.out.println("Message: ");
> System.out.println(message.toString());
> System.out.println("Sleep...");
> Thread.sleep(3);  // 2 works, 3 does not.
> System.out.println("Wake up");
> System.out.println("Do manual ACK");
> message.acknowledge();
> connection.close();} catch (Exception exp) {
> exp.printStackTrace(System.out);
> }
> }private static class MyExceptionListener implements
> ExceptionListener {
> @Override
> public void onException(JMSException exception) {
> System.out.println("Connection ExceptionListener fired,
> exiting.");
> exception.printStackTrace(System.out);
> System.exit(1);
> }
> }
> }
>
>
> It seems that there is an internal "timeout" value that is returning the
> message to the queue before we are done processing it. Can this value be
> somehow increased?
>
> Thanks in advance!
>
> Martín Paoloni
>

Re: Migrate 0.20 XML configs to 6.1.4 JSON configs

[Rob Godfrey]

On Thu, 21 Nov 2019 at 19:03, Kristofor Horst  wrote:

> Hello,
>
> Is there a generally accepted best practice/tool that can easily migrate an
> xml configuration compatible with qpid 0.20 to the json format required of
> 6.1.4?
>

Wow - that's an old version :) - looking back 0.20 was released in January
2013, almost 7 years ago!


>
> I've manually entered the information but it is very time consuming if I
> have to do so in the future. Also, it is prone to human error in
> transcription in this way so I would prefer a tool if one is available.
>
>
I think the suggestion back in the original timeframe that the changes were
made was to load the XML config into a 0.22 (or maybe later - maybe someone
with a better memory than me can recall) broker and then extract the
configuration as JSON via the HTTP management API.  There is this mail
thread
http://qpid.2158936.n2.nabble.com/Qpid-0-22-how-to-pass-in-xml-config-file-tp7595486.html
which talks about how to use virtualhosts.xml on a 0.22 broker.  I couldn't
immediately find anything on extracting using HTTP.


> I was not able to find any posting for this topic in the archive, so my
> inclination is that you must do it manually.
>
> Furthermore, if I am change controlling my configuration files, can I be
> guaranteed that the order of the file will remain unchanged when a new
> queue
> or exchange is added?
>

As far as I remember, the broker will always store configuration in a
stable order - however if the config is edited outside of the broker, then
that order will not be maintained - rather the config will be written in
the order the broker will always sort it.


>
> The order remaining unchanged facilitates doing a file compare to check my
> inclusions.
>
> Thanks,
> Kristofor
>
>
>
Hope this helps in some way.

-- Rob


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

Re: [Broker-J] REST-API: how to determine consumer for acquired messages

[Rob Godfrey]

So I've pushed a change that will return the consumerId of the acquiring
consumer - so for an acquired message you'd additionally something like:

"deliveredToConsumerId" : "406c1d71-1189-41bf-a945-6d21f5fd0753"

Does that meet your requirements?

Thanks,
Rob

On Wed, 6 Nov 2019 at 01:54, Timo Naroska 
wrote:

> https://issues.apache.org/jira/browse/QPID-8373
>
> Thanks,
> Timo
>
> On 11/5/19, 3:53 PM, "Oleksandr Rudyy"  wrote:
>
> Hi Timo,
>
> I think that the reason behind providing consumerNumber in
> 'deliveredTo'
> field was to allow to find the consumer in operational logs.The
> consumer
> number is reported in operational logs due to historical reasons.
> I agree that it make more sense for this REST operation to provide the
> consumer id in  'deliveredTo' field.
> Please raise a JIRA to request the change.
>
> Kind regards,
> Alex
>
> On Tue, 5 Nov 2019 at 23:13, Timo Naroska 
> wrote:
>
> > Hi,
> >
> > for monitoring purposes we're looking for a way to retrieve the
> current
> > messages from a queue and which consumer, if any, is currently
> processing
> > them.
> >
> > I found the getMessageInfo operation on Queue objects which
> enumerates
> > messages. I can determine messages that are currently processed by
> > filtering for state 'Acquired'. However, I don't see a way to
> determine
> > which specific consumer has acquired which messages.
> > There is a 'deliveredTo' field, but the value is some internal
> > _consumerNumber attribute of the consumer that seems to be used
> nowhere
> > else in the REST API.
> >
> > Would it be possible to return the actual consumer ID in the
> deliveredTo
> > field to make it more useful?
> > Another option would be to add the _consumerNumber to the result of
> the
> > Queue getConsumers operation. That would allow cross reference.
> >
> > Any other suggestion? Again I'm looking for a way to determine the
> > consumer that has currently acquired a message from the queue.
> >
> > Thanks
> > Timo
> >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Broker-J] REST-API: getMessageInfo does not list message groupIds

[Rob Godfrey]

Committed as QPID-8380 <https://issues.apache.org/jira/browse/QPID-8380>.

Alex - another candidate for the next 7.1.x release I think

-- Rob

On Tue, 19 Nov 2019 at 10:11, Rob Godfrey  wrote:

> Hi
>
> On Tue, 19 Nov 2019 at 00:27, Timo Naroska 
> wrote:
>
>> Hi,
>>
>> we’re using Qpid’s message grouping feature and are sending messages
>> through Qpid java client with the JMSXGroupID property. This is working
>> great.
>>
>>
> Good to hear!
>
>
>> We noticed that when using the getMessageInfo REST API there is no way to
>> retrieve the groupId for enqueued messages.
>> There is no field in the top-level JSON doc, but there is also no
>> JMSXGroupID entry in the headers dictionary when passing includeHeaders=true
>>
>>
> I presume you are using AMQP 1.0 then :) In older AMQP versions the value
> was placed in the header - which is probably why it wasn't explicitly
> called out in the MessageInfo
>
>
>> Is there another way to get this information?
>> This seems to be a bug in the REST API.
>>
>
> It's an omission certainly.  I'll raise a JIRA and create a fix shortly.
>
> Thanks,
> Rob
>
>
>>
>> Best
>> Timo
>>
>>

Re: [Broker-J] REST-API: getMessageInfo does not list message groupIds

[Rob Godfrey]

Hi

On Tue, 19 Nov 2019 at 00:27, Timo Naroska 
wrote:

> Hi,
>
> we’re using Qpid’s message grouping feature and are sending messages
> through Qpid java client with the JMSXGroupID property. This is working
> great.
>
>
Good to hear!


> We noticed that when using the getMessageInfo REST API there is no way to
> retrieve the groupId for enqueued messages.
> There is no field in the top-level JSON doc, but there is also no
> JMSXGroupID entry in the headers dictionary when passing includeHeaders=true
>
>
I presume you are using AMQP 1.0 then :) In older AMQP versions the value
was placed in the header - which is probably why it wasn't explicitly
called out in the MessageInfo


> Is there another way to get this information?
> This seems to be a bug in the REST API.
>

It's an omission certainly.  I'll raise a JIRA and create a fix shortly.

Thanks,
Rob


>
> Best
> Timo
>
>

Re: Qpid as a RabbitMQ broker for Java app integration tests - exchange declare arguments

[Rob Godfrey]

On Mon, 18 Nov 2019 at 13:42, Lukasz Guzik 
wrote:

> Hi Rob,
>
> Yes, this is a perfect solution for me, thank you! :)
> Could you please let me know when it will be released?
>
>
Alex - do we have a plan for the next release yet?

-- Rob


> niedz., 17 lis 2019 o 23:30 Rob Godfrey 
> napisał(a):
>
>> Hi Łukasz,
>>
>> I have made an enhancement to the Broker as QPID-8377
>> <https://issues.apache.org/jira/browse/QPID-8377> along the lines I
>> suggested in my previous mail.  I hope this will meet your requirements.
>>
>> Thanks,
>> Rob
>>
>> On Mon, 11 Nov 2019 at 09:33, Rob Godfrey 
>> wrote:
>>
>>> Hi Łukasz,
>>>
>>> firstly let me apologise for not getting back to you sooner.
>>>
>>> Secondly, unfortunately I agree that there is no current way to
>>> explicitly tell the broker to ignore unknown exchange declare arguments,
>>> and that adding this ability is a good idea.  The simplest approach is
>>> probably to add a configurable property to the VirtualHost for
>>> "unknownExchangeDeclareArgumentPolicy" (or something like that) with
>>> options of FAIL, LOG and IGNORE (where the current behaviour - FAIL - would
>>> be the default).  If that seems reasonable to you we can raise a JIRA and
>>> make a change.
>>>
>>> Thanks,
>>> Rob
>>>
>>> On Mon, 4 Nov 2019 at 13:31, Lukasz Guzik 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm working on using Qpid broker as an in-memory AMQP message broker,
>>>> that
>>>> will be used in place of RabbitMQ for integration tests of my Java
>>>> service.
>>>> While I managed to successfully run Qpid, I'm having issues with my
>>>> RabbitMQ connector library using some RMQ-specific exchange declare
>>>> arguments. Basically, Qpid refuses to create an exchange with error:
>>>> Unsupported exchange declare arguments: x-ha-policy,ha-mode.
>>>> Is there any option to make Qpid ignore these arguments, or to write a
>>>> custom handler for these (that will basically do nothing)? I wasn't
>>>> able to
>>>> find any solution in the docs nor over the internet, unfortunately.
>>>>
>>>> Thank you!
>>>>
>>>> --
>>>>
>>>> Łukasz Guzik
>>>>
>>>> Senior Software Engineer
>>>>
>>>> lukasz.gu...@beekeeper.io
>>>>
>>>> Beekeeper · beekeeper.io · We are hiring
>>>> <https://www.beekeeper.io/en/company/jobs>
>>>>
>>>> Beekeeper AG, Pawia 9, 31-154 Cracow, Poland
>>>>
>>>> https://www.beekeeper.io/en/company/jobs
>>>>
>>>
>
> --
>
> Łukasz Guzik
>
> Senior Software Engineer
>
> lukasz.gu...@beekeeper.io
>
> Beekeeper · beekeeper.io · We are hiring
> <https://www.beekeeper.io/en/company/jobs>
>
> Beekeeper AG, Pawia 9, 31-154 Cracow, Poland
>
> https://www.beekeeper.io/en/company/jobs
>

Re: Qpid as a RabbitMQ broker for Java app integration tests - exchange declare arguments

[Rob Godfrey]

Hi Łukasz,

I have made an enhancement to the Broker as QPID-8377
<https://issues.apache.org/jira/browse/QPID-8377> along the lines I
suggested in my previous mail.  I hope this will meet your requirements.

Thanks,
Rob

On Mon, 11 Nov 2019 at 09:33, Rob Godfrey  wrote:

> Hi Łukasz,
>
> firstly let me apologise for not getting back to you sooner.
>
> Secondly, unfortunately I agree that there is no current way to explicitly
> tell the broker to ignore unknown exchange declare arguments, and that
> adding this ability is a good idea.  The simplest approach is probably to
> add a configurable property to the VirtualHost for
> "unknownExchangeDeclareArgumentPolicy" (or something like that) with
> options of FAIL, LOG and IGNORE (where the current behaviour - FAIL - would
> be the default).  If that seems reasonable to you we can raise a JIRA and
> make a change.
>
> Thanks,
> Rob
>
> On Mon, 4 Nov 2019 at 13:31, Lukasz Guzik 
> wrote:
>
>> Hello,
>>
>> I'm working on using Qpid broker as an in-memory AMQP message broker, that
>> will be used in place of RabbitMQ for integration tests of my Java
>> service.
>> While I managed to successfully run Qpid, I'm having issues with my
>> RabbitMQ connector library using some RMQ-specific exchange declare
>> arguments. Basically, Qpid refuses to create an exchange with error:
>> Unsupported exchange declare arguments: x-ha-policy,ha-mode.
>> Is there any option to make Qpid ignore these arguments, or to write a
>> custom handler for these (that will basically do nothing)? I wasn't able
>> to
>> find any solution in the docs nor over the internet, unfortunately.
>>
>> Thank you!
>>
>> --
>>
>> Łukasz Guzik
>>
>> Senior Software Engineer
>>
>> lukasz.gu...@beekeeper.io
>>
>> Beekeeper · beekeeper.io · We are hiring
>> <https://www.beekeeper.io/en/company/jobs>
>>
>> Beekeeper AG, Pawia 9, 31-154 Cracow, Poland
>>
>> https://www.beekeeper.io/en/company/jobs
>>
>

Re: Broker-J statistics and CPU consumption

[Rob Godfrey]

On Sun, 17 Nov 2019 at 22:37, VERMEULEN Olivier 
wrote:

> Thanks Rob.
>
> This will help us a lot in monitoring the brokers.
> By the way, any chance we can get something similar on the dispatch-router
> side?
>

Probably worth starting a separate thread on that topic, as it's likely
that the Dispatch developers will skip this thread due to its title :-)

-- Rob


>
> Olivier
>
> -Original Message-
> From: Rob Godfrey 
> Sent: dimanche 17 novembre 2019 13:36
> To: users@qpid.apache.org
> Subject: Re: Broker-J statistics and CPU consumption
>
> I've created the JIRA QPID-8376
> <https://issues.apache.org/jira/browse/QPID-8376> and made a change there
> which adds two statistics - processCpuTime (which is the cumulative CPU
> time since the app started) and processCpuLoad (which is the current CPU
> load due to the process, rounded to 4 decimal places) which will be
> retrieved if the underlying Java platform supports them.
>
> Hope this helps,
> Rob
>
> On Fri, 15 Nov 2019 at 23:05, Rob Godfrey  wrote:
>
> >
> >
> > On Fri, 15 Nov 2019 at 21:21, Oleksandr Rudyy  wrote:
> >
> >> Hi Olivier,
> >>
> >> CPU consumption statistic is not available.
> >> Potentially, cpu average load from
> >> java.lang.management.OperatingSystemMXBean#getSystemLoadAverage can
> >> be returned as part of broker statistics.
> >> If you need OperatingSystemMXBean#getSystemLoadAverage() being
> >> exposed as broker statistic, please raise JIRA.
> >>
> >
> > I'm not sure there is huge value in reporting on the SystemLoadAverage
> > - that is the total load on the system, rather than just the load the
> > Broker is generating I think.  As such it seems weird to ask the
> > Broker to report on it.  As per my (very slightly earlier than yours)
> > mail - there does seem to be a mechanism on at least some Sun/Oracle
> > JVMs to get the Process CPU time.  Again I'm still somewhat dubious as
> > to whether this should be gather from the broker itself, or whether
> > this is more properly reported using some sort of external monitoring
> tool.
> >
> > -- Rob
> >
> >
> >>
> >> Kind Regards,
> >> Alex
> >>
> >> On Fri, 15 Nov 2019 at 16:31, VERMEULEN Olivier <
> >> olivier.vermeu...@murex.com>
> >> wrote:
> >>
> >> > Hello,
> >> >
> >> > We're using the Broker-J 7.1.3.
> >> > Looking at the statistics provided by
> >> > /api/latest/broker/getStatistics,
> >> I
> >> > don't see anything related to the CPU consumption.
> >> > Did I miss something or this information is not provided?
> >> >
> >> > 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.
>

Re: Broker-J statistics and CPU consumption

[Rob Godfrey]

I've created the JIRA QPID-8376
<https://issues.apache.org/jira/browse/QPID-8376> and made a change there
which adds two statistics - processCpuTime (which is the cumulative CPU
time since the app started) and processCpuLoad (which is the current CPU
load due to the process, rounded to 4 decimal places) which will be
retrieved if the underlying Java platform supports them.

Hope this helps,
Rob

On Fri, 15 Nov 2019 at 23:05, Rob Godfrey  wrote:

>
>
> On Fri, 15 Nov 2019 at 21:21, Oleksandr Rudyy  wrote:
>
>> Hi Olivier,
>>
>> CPU consumption statistic is not available.
>> Potentially, cpu average load from
>> java.lang.management.OperatingSystemMXBean#getSystemLoadAverage can be
>> returned as part of broker statistics.
>> If you need OperatingSystemMXBean#getSystemLoadAverage() being exposed as
>> broker statistic, please raise JIRA.
>>
>
> I'm not sure there is huge value in reporting on the SystemLoadAverage -
> that is the total load on the system, rather than just the load the Broker
> is generating I think.  As such it seems weird to ask the Broker to report
> on it.  As per my (very slightly earlier than yours) mail - there does seem
> to be a mechanism on at least some Sun/Oracle JVMs to get the Process CPU
> time.  Again I'm still somewhat dubious as to whether this should be gather
> from the broker itself, or whether this is more properly reported using
> some sort of external monitoring tool.
>
> -- Rob
>
>
>>
>> Kind Regards,
>> Alex
>>
>> On Fri, 15 Nov 2019 at 16:31, VERMEULEN Olivier <
>> olivier.vermeu...@murex.com>
>> wrote:
>>
>> > Hello,
>> >
>> > We're using the Broker-J 7.1.3.
>> > Looking at the statistics provided by /api/latest/broker/getStatistics,
>> I
>> > don't see anything related to the CPU consumption.
>> > Did I miss something or this information is not provided?
>> >
>> > 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.
>> >
>>
>

Re: Broker-J statistics and CPU consumption

[Rob Godfrey]

On Fri, 15 Nov 2019 at 21:21, Oleksandr Rudyy  wrote:

> Hi Olivier,
>
> CPU consumption statistic is not available.
> Potentially, cpu average load from
> java.lang.management.OperatingSystemMXBean#getSystemLoadAverage can be
> returned as part of broker statistics.
> If you need OperatingSystemMXBean#getSystemLoadAverage() being exposed as
> broker statistic, please raise JIRA.
>

I'm not sure there is huge value in reporting on the SystemLoadAverage -
that is the total load on the system, rather than just the load the Broker
is generating I think.  As such it seems weird to ask the Broker to report
on it.  As per my (very slightly earlier than yours) mail - there does seem
to be a mechanism on at least some Sun/Oracle JVMs to get the Process CPU
time.  Again I'm still somewhat dubious as to whether this should be gather
from the broker itself, or whether this is more properly reported using
some sort of external monitoring tool.

-- Rob


>
> Kind Regards,
> Alex
>
> On Fri, 15 Nov 2019 at 16:31, VERMEULEN Olivier <
> olivier.vermeu...@murex.com>
> wrote:
>
> > Hello,
> >
> > We're using the Broker-J 7.1.3.
> > Looking at the statistics provided by /api/latest/broker/getStatistics, I
> > don't see anything related to the CPU consumption.
> > Did I miss something or this information is not provided?
> >
> > 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.
> >
>

Re: Broker-J statistics and CPU consumption

[Rob Godfrey]

Hi Olivier,

no - there is nothing on CPU consumption.  I don't believe there is any
standard way to get the CPU consumption from a Java process.

The closest I can find is that if the platform implementation of
OperatingSystemMXBean implements com.sun.management.OperatingSystemMXBean
then it will provide a long getProcessCpuTime() method.

Theoretically that could be added to the BrokerAttributeInjector in the
Qpid Broker-J codebase (in the same style as the other statistics are added
in that class).

-- Rob



On Fri, 15 Nov 2019 at 17:31, VERMEULEN Olivier 
wrote:

> Hello,
>
> We're using the Broker-J 7.1.3.
> Looking at the statistics provided by /api/latest/broker/getStatistics, I
> don't see anything related to the CPU consumption.
> Did I miss something or this information is not provided?
>
> 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.
>

Re: Qpid as a RabbitMQ broker for Java app integration tests - exchange declare arguments

[Rob Godfrey]

Hi Łukasz,

firstly let me apologise for not getting back to you sooner.

Secondly, unfortunately I agree that there is no current way to explicitly
tell the broker to ignore unknown exchange declare arguments, and that
adding this ability is a good idea.  The simplest approach is probably to
add a configurable property to the VirtualHost for
"unknownExchangeDeclareArgumentPolicy" (or something like that) with
options of FAIL, LOG and IGNORE (where the current behaviour - FAIL - would
be the default).  If that seems reasonable to you we can raise a JIRA and
make a change.

Thanks,
Rob

On Mon, 4 Nov 2019 at 13:31, Lukasz Guzik  wrote:

> Hello,
>
> I'm working on using Qpid broker as an in-memory AMQP message broker, that
> will be used in place of RabbitMQ for integration tests of my Java service.
> While I managed to successfully run Qpid, I'm having issues with my
> RabbitMQ connector library using some RMQ-specific exchange declare
> arguments. Basically, Qpid refuses to create an exchange with error:
> Unsupported exchange declare arguments: x-ha-policy,ha-mode.
> Is there any option to make Qpid ignore these arguments, or to write a
> custom handler for these (that will basically do nothing)? I wasn't able to
> find any solution in the docs nor over the internet, unfortunately.
>
> Thank you!
>
> --
>
> Łukasz Guzik
>
> Senior Software Engineer
>
> lukasz.gu...@beekeeper.io
>
> Beekeeper · beekeeper.io · We are hiring
> 
>
> Beekeeper AG, Pawia 9, 31-154 Cracow, Poland
>
> https://www.beekeeper.io/en/company/jobs
>

Re: Are generated Ids secure + permanent?

[Rob Godfrey]

Hi Kristofor,



On Thu, 10 Oct 2019 at 20:17, Kristofor Horst  wrote:

> Hello,
>
> When a queue is generated via the UI/web API and written to the config.json
> file, is the ID created for it securely generated and permanent?
>
>
The IDs are generated from java.util.UUID.randomUUID() -
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/UUID.html#randomUUID()

I'm not entirely sure what you mean by "permanent": the ID is the
identifier for the queue.  If you modify the ID then it effectively becomes
a new queue (messages on a queue reference the queue by ID, not by the
queue name, so if you edit the config file, change the queue's id and
restart, then the queue with the same name will no longer have messages.

As to how securely generated... you'd have to ask Oracle, or go look at the
source code yourself.


> I manage several dozen queues across a few instances of the qpid broker (on
> separate boxes), but I am concerned that I may have collisions occur
> between
> IDs if the config files are regenerated by my management processes,
> potentially all simultaneously.
>

Many other factors are involved other than simple timing, so I don't think
you'll ever see duplicates (I certainly haven't).


>
> Thanks,
>
> Kristofor
>
>
Hope this helps,
Rob


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

Re: [Broker-J] Question about SUB-1003: Suspended for 10,001 ms

[Rob Godfrey]

On Fri, 11 Oct 2019 at 23:20, Tom Jordahl 
wrote:

> Hello,
>
> I am hoping someone can give me a little more background on why I am
> receiving the following messages in my broker logs:
> 2019-10-11 10:32:10,278 INFO [IO-/10.110.54.132:41086] (q.m.s.state) -
> [IO Pool] [sub:248(vh(/MyVHost)/qu(MyHighVolumeQ)] SUB-1003 : Suspended for
> 10,001 ms
>
> I have found this [1]:
>   > consumer.suspendNotificationPeriod Governs the length of time that a
> consumer
>   > may remain suspended before the the Broker begins to produce SUB-1003<
> https://qpid.apache.org/releases/qpid-broker-j-7.1.5/book/Java-Broker-Appendix-Operation-Logging.html#Java-Broker-Appendix-Operation-Logging-Message-SUB-1003>
> operational log messages.
>
> And also have read this [2]:
>   > Indicates that a subscription has been in a suspened state for an
> unusual length of time.
>   > This may be indicative of an consuming application that has stopped
> taking messages from the consumer
>   > (i.e. a JMS application is not calling receive() or its asynchronous
> message listener
>   > onMessage() is blocked in application code). It may also indicate a
> generally overloaded system.
>
> I am interpreting “its asynchronous message listener onMessage() is
> blocked in application code” as indicating that something is just taking
> more that 10 seconds to consume a message.  I may just be getting confused
> by the word “suspended” here, meaning that the broker is just waiting
> around for the consumer to get on with acknowledging the successful
> processing of a message.
>
> QUESTIONS
> - Is this simply an indicator that the consumers are taking a long time to
> service messages?  I do have consumers that can take upwards of 30-60
> seconds to complete message processing under load.
>

Yes


> - Is this message “mostly harmless”?  i.e. is Qpid just telling me I have
> a slow consumer?
>
>
Yes.

The term "suspended" is not the greatest, but is somewhat historical from
the original implementation.  As you say, the message is harmless, but can
be very useful in diagnosing issues that are seen in production "why are
there no messages flowing... ah the broker is saying this consumer is
suspended... maybe it is not acking correctly", etc.


> If it matters, I am using Broker-J 7.1.4 on CentOS.
>
> [1]
> https://qpid.apache.org/releases/qpid-broker-j-7.1.5/book/Java-Broker-Management-Managing-Consumers.html
> [2]
> https://qpid.apache.org/releases/qpid-broker-j-7.1.5/book/Java-Broker-Appendix-Operation-Logging.html#Java-Broker-Appendix-Operation-Logging-Message-SUB-1003
>
> Thanks for any info.
>

Hope this helps,
Rob


> --
> Tom
>
>

Re: [VOTE] Release Qpid Broker-J 7.1.5

[Rob Godfrey]

+1

Built from source
Tested using AMQP 1.0 and 0-9-1 protocols, Memory and BDB stores.
Manually tested the web console
Simple send / receive tests

-- Rob


On Sun, 6 Oct 2019 at 12:59, Oleksandr Rudyy  wrote:

> +1
>
> My tests are listed below
> * verified signatures and checksums
> * successfully built broker artefacts and ran tests from source bundle
> * manually tested Kerberos authentication on Fedora 29 with Kerberos server
> version 1.16.1-25
> ** successfully created of Kerberos authentication provider from Web
> Management Console
> ** successfully logged into  Web Management Console using SPNEGO
> ** successfully established connections from JMS client 0.45.0 on AQMP port
> with Kerberos authentication
>
>
> On Sun, 6 Oct 2019 at 11:26, 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
> >
>

Re: [Qpid Broker-J] Reload FileKeyStore

[Rob Godfrey]

On Thu, 1 Aug 2019 at 13:21, .. ...  wrote:

> Hi Alex, Rob,
>
> SNI matching can result in list of certificates for particular host.
> Certificate alias option specifies always single certificate. Because
> certificate alias option is more restrictive, I thought it will have higher
> priority than SNI.
>

No - because if it always used the alias then there'd be no point in doing
SNI matching in addition :-) .

The SNI matching is designed for the case where you have multiple distinct
hostnames (with different certs) and you want to serve the correct cert for
the given hostname.

The way it works now is that it only uses the alias if there is no match.
If there is an SNI match, it will only return a valid cert (so it will not
return a new cert if it is not yet valid).  If the cert is not valid or
compromised then you really should remove it from the keystore.

-- Rob


>
> For instance corner case where selecting certificate with SNI enabled could
> be helpful:
> * Host certificate will expire in one month
> * New host certificate is created, added to keystore with different alias
> and distributed to client
> * Client for some reason wants to use new certificate before old
> certificate expires (for instance certificate was compromised, ...)
> * Old certificate have to be physically removed from keystore, because both
> certificates are valid and broker picks first one. If "Certificate alias"
> would have higher priority, then certificate alias can be set in webgui
> without touching any file on filesystem
>
> But this situation can be also solved by disabling SNI in webgui and broker
> will offer correct certificate (if certificate alias set).
>
> Maybe it will be clearer if options "SNI host matching" and "Certificate
> alias" will be exclusive -> Certificate alias can be set only if "SNI host
> matching" is disabled.
>
> Regards,
> Tomas
>
> On Thu, Aug 1, 2019 at 10:31 AM Oleksandr Rudyy  wrote:
>
> > Hi Rob,
> >
> > Thanks for detailed explanation of rationale behind current
> > implementation..
> >
> > I guess, that Tomas is looking for a way to be able to select certificate
> > from multiple with matching SNI host name. It feels like he needs an
> alias
> > per host name rather than just one default alias.
> > I am speculating, as I am not sure what are the real use cases here.
> >
> > Kind Regards,
> > Alex
> >
> >
> > On Wed, 31 Jul 2019 at 17:36, Rob Godfrey 
> wrote:
> >
> > > On Wed, 31 Jul 2019 at 17:37, Oleksandr Rudyy 
> wrote:
> > >
> > > > Tomas,
> > > > Thanks for clarification.
> > > >
> > > > I am actually curious about your keystore setup. Why do you need
> > multiple
> > > > valid certificates with matching SNI host name? Perhaps, I missing
> some
> > > > useful use cases. In that case, I can update keystore implementation
> to
> > > use
> > > > alias to pick up the right certificate among several valid ones.
> > > >
> > >
> > > The current design is quite deliberate - I don't think it makes sense
> to
> > > apply the alias if SNI matching in in effect and a match has been made.
> > If
> > > the store has certs for hosts A, two certs for B and two certs for C
> ...
> > > and the alias point at one of the certs for C... what should be done in
> > the
> > > case where a connection is made that matches host B... surely it
> doesn't
> > > make sense to use one of the certs for C (which prioritising the alias
> > > would imply).  Basically if you are using SNI matching I think that
> > always
> > > needs to take priority, and you would only use the alias in the case
> > there
> > > is no match.
> > >
> > > -- Rob
> > >
> > >
> > >
> > > >
> > > > The keystore documentation needs to be updated to highlight how  it
> > works
> > > > with "SNI host name matching" and alias configured.
> > > >
> > > > Kind Regards,
> > > > Alex
> > > >
> > > > On Wed, 31 Jul 2019 at 11:33, .. ... 
> wrote:
> > > >
> > > > > Hi Alex,
> > > > >
> > > > > I thought that property "Certificate alias" have higher priority
> than
> > > > "SNI
> > > > > host name matching".
> > > > >
> > > > > If I understand it correctly, there is no way to tell broker which
> > > > > certificate alias broker should use if there are 

Re: [Qpid Broker-J] Reload FileKeyStore

[Rob Godfrey]

On Wed, 31 Jul 2019 at 17:37, Oleksandr Rudyy  wrote:

> Tomas,
> Thanks for clarification.
>
> I am actually curious about your keystore setup. Why do you need multiple
> valid certificates with matching SNI host name? Perhaps, I missing some
> useful use cases. In that case, I can update keystore implementation to use
> alias to pick up the right certificate among several valid ones.
>

The current design is quite deliberate - I don't think it makes sense to
apply the alias if SNI matching in in effect and a match has been made.  If
the store has certs for hosts A, two certs for B and two certs for C ...
and the alias point at one of the certs for C... what should be done in the
case where a connection is made that matches host B... surely it doesn't
make sense to use one of the certs for C (which prioritising the alias
would imply).  Basically if you are using SNI matching I think that always
needs to take priority, and you would only use the alias in the case there
is no match.

-- Rob



>
> The keystore documentation needs to be updated to highlight how  it works
> with "SNI host name matching" and alias configured.
>
> Kind Regards,
> Alex
>
> On Wed, 31 Jul 2019 at 11:33, .. ...  wrote:
>
> > Hi Alex,
> >
> > I thought that property "Certificate alias" have higher priority than
> "SNI
> > host name matching".
> >
> > If I understand it correctly, there is no way to tell broker which
> > certificate alias broker should use if there are multiple valid
> > certificates matching SNI hostname and "SNI host name matching" is set to
> > true.
> >
> > Now when I know how certificate selection works, I think there is no
> > problem. I will set "SNI host matching" to false and broker will offer
> > certificate specified by "Certificate alias".
> >
> > Thanks for clarifying.
> >
> > Regards,
> > Tomas
> >
> > On Wed, Jul 31, 2019 at 2:29 AM Oleksandr Rudyy 
> wrote:
> >
> > > Hi Tomas,
> > >
> > > I quickly looked through the implementation of FileKeyStore and how
> > aliases
> > > used.
> > > The code looks Ok to me.
> > >
> > > Could you please provide more details about your alias problem?
> > >
> > > Do you use "SNI host name matching"?
> > >
> > > Please note that with the latter set to "true", the SNI host name is
> used
> > > to pick up a certificate.
> > > If there are multiple certificates matching SNI host name, the first
> > valid
> > > one is selected. If there is no valid certificate, but  a number of
> > invalid
> > > certificates matching SNI is found, the first invalid is selected. The
> > > alias is used only when store does not have valid or invalid
> certificates
> > > matching SNI host name.
> > >
> > > I will appreciate if you could provide more information about your
> alias
> > > issue.
> > >
> > > Kind Regards,
> > > Alex
> > >
> > > [1]
> > >
> > >
> >
> http://qpid.2158936.n2.nabble.com/Java-Broker-Select-certificate-from-broker-keystore-td7673701.html
> > >
> > > On Tue, 30 Jul 2019 at 10:03, .. ...  wrote:
> > >
> > > > Hi Alex,
> > > >
> > > >
> > > >
> > > > I personally think explicit reload is good approach. With explicit
> > reload
> > > > we can control when keystore/truststore will be reloaded. In case of
> > > > automatic background checks, attacker can compromise truststore and
> > > > compromised truststore will be automatically reloaded by broker.
> > > >
> > > >
> > > >
> > > > Note: Certificate aliases are broken in 7.1.x as well as in master.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Tomas
> > > >
> > > >
> > > >
> > > > 
> > > >
> > > > Hi Tomas,
> > > >
> > > >
> > > >
> > > > The reload operation in FileKeyStore only updates certificate data as
> > > they
> > > >
> > > > are cached. The key managers are re-created from keystore every time
> on
> > > >
> > > > ports opening. That's why reload of FileKeyStore is not really
> > required.
> > > >
> > > > For the file trust stores, the trust managers are cached and updated
> by
> > > >
> > > > reload operation.
> > > >
> > > >
> > > >
> > > > Potentially, instead of having explicit reload operations, the
> > background
> > > >
> > > > checks can be implemented to watch for keystore file modification in
> > > order
> > > >
> > > > to update all cached data promptly.
> > > >
> > > > What do you think about this approach?
> > > >
> > > >
> > > >
> > > > Thanks for providing the link to discussion about certificate
> aliases.
> > > I'll
> > > >
> > > > check what broke it in 7.1.
> > > >
> > > >
> > > >
> > > > Kind Regards,
> > > >
> > > > Alex
> > > >
> > > >
> > > >
> > > > On Mon, 29 Jul 2019 at 14:34, .. ... vavricka.tomas@
> > > > 
> > > > wrote:
> > > > 
> > > >
> > > > On Mon, Jul 29, 2019 at 7:40 PM Oleksandr Rudyy 
> > > wrote:
> > > >
> > > > > Hi Tomas,
> > > > >
> > > > > The reload operation in FileKeyStore only updates certificate data
> as
> > > > they
> > > > > are cached. The key managers are re-created from keystore every
> time
> > on
> > > > > ports opening. That's why reload of 

Re: [QPID Broker-J] Flow control does not stall the client

[Rob Godfrey]

Hi Martin,

On Thu, 18 Jul 2019 at 15:55, Martin Krása  wrote:

> Hello,
>
> I have installed Java broker version 7.1.5-SNAPSHOT (last commit
> 4dd26ddd0263fac22d91a0a16c48789592a9ccb2). Using QPID JMS Client
> 0.40.0 producer I sent valid messages to the exchange. All messages
> end up in the queue, as expected.
>
> When the number of messages sent exceed queue count the broker
> produces INFO message:
>
> “CHN-1005 : Flow Control Enforced (Queue queue)”
>
> After that the client is able to continue to send all the remaining
> messages, the broker settles every single one of the messages sent.
>
> I have tested that the queue receives all the messages sent even if
> either the queue count or queue size are smaller than the number of
> messages and/or size of all messages sent by the client.
>
> I would expect the client to be stalled/stopped until either the queue
> count or queue size decrease below the queueFlowResumeLimit.
>


So, currently flow control on the queues is only enacted if you send
directly to the queue (rather than via an exchange).  This is because for
AMQP the flow control is on the destination of the link and if the
destination is an exchange then there is no way to control the message flow
to a specific queue before the message is sent.  One particular problem
here is if the anonymous exchange/terminus is used... i.e. a single link is
created for publishing messages and all inbound messages go over that link
rather than a different link for each queue.  I believe this is the default
behaviour for the Qpid JMS client, which is why you would not se flow
control.

-- Rob


>
> Is there any configuration I might be missing?
>
> For broker configuration please see attached flowcontrol_json.txt file.
>
> Regards
> Martin
>
> -
> 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.0.8

[Rob Godfrey]

On Fri, 5 Jul 2019 at 12:30, Robbie Gemmell 
wrote:

> FWIW the test is passing for me on two different Fedora systems with
> OpenJDK 1.8.0_212 and Oracle JDK 1.8.0_181, but the log does suggest
> an issue which could very well be the one you point to. Especially
> since the JIRA is marked fixed in 7.1.0 and so could also explain any
> difference from the 7.1.4 release under vote if the test hasnt changed
> between the branches. Though oddly, Gordon and Rob have tested 7.0.x
> before and not reported this issue, so is it a new test?
>

So the failure is completely environment dependent.  IIRC, for example, the
test passes when I'm on my UK ISP because it has a "broken" DNS resolver
that resolves unknown hostnames to their own IP address.  I've never had
the issue on Fedora, only on OS X.  I don't actually remember what I tested
7.0.7 on.  I remembered that I often got this error, and that I thought I
fixed it, but had forgotten the exact JIRA until Alex found it :-).


>
> Robbie
>
> On Fri, 5 Jul 2019 at 11:09, Oleksandr Rudyy  wrote:
> >
> > Gordon,
> >
> > Thanks for the logs. Though, there is nothing interesting there which
> would
> > shed light over the failure cause.
> >
> > The log file contain a record for receiving OPEN performative, and, after
> > that, in 6 seconds the test fails.
> >
> > Rob reported QPID-8150 [1] about issues with time taken by hostname
> > resolution. There are port host aliases configured in broker
> configuration
> > which are resolving host names. On some environments it take a lot of
> time.
> >   It could be potential reason for the test failure.
> >
> > What is your environment?
> >
> > You can remove the hostname alias entry from the broker test
> configuration
> > to make sure that it does not impact the test.
> >
> > The diff is below
> >
> > $ git diff
> > diff --git
> >
> a/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> >
> b/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> > index 764ff891a..522fd5bea 100644
> > ---
> >
> a/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> > +++
> >
> b/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> > @@ -47,9 +47,6 @@
> >  "virtualhostaliases" : [ {
> >"name" : "defaultAlias",
> >"type" : "defaultAlias"
> > -}, {
> > -  "name" : "hostnameAlias",
> > -  "type" : "hostnameAlias"
> >  }, {
> >"name" : "nameAlias",
> >"type" : "nameAlias"
> > @@ -64,10 +61,6 @@
> >"name" : "defaultAlias",
> >"type" : "defaultAlias",
> >"durable" : true
> > -}, {
> > -  "name" : "hostnameAlias",
> > -  "type" : "hostnameAlias",
> > -  "durable" : true
> >  }, {
> >"name" : "nameAlias",
> >"type" : "nameAlias",
> >
> >
> > I hope that the above should fix the issue.
> >
> > Kind Regards,
> > Alex
> >
> > [1] https://issues.apache.org/jira/browse/QPID-8150
> >
> >
> > On Fri, 5 Jul 2019 at 09:54, Gordon Sim  wrote:
> >
> > > On 05/07/2019 9:26 am, Oleksandr Rudyy wrote:
> > > > Hi Gordon,
> > > >
> > > > Thanks for testing the release and reporting a test failure.
> > > >
> > > > The failed test sends open performative against non existing virtual
> host
> > > > and expects to receive an "open" back containing an error
> > > "amqp:not-found"
> > > > within 6 seconds after sending "open".
> > > > The failure occurred because "open" was not received within 6
> seconds. It
> > > > could be environmental. For example, a long GC "stop the world"
> pause can
> > > > cause it, or, environment in use could be slow.
> > >
> > > I did run all the tests a second time and again it failed on that
> > > specific test only. (Not that that necessarily rules out your
> hypothesis)
> > >
> > > > The test logs could provide more details about test execution.
> > > >
> > > > If you still have a test log file
> > > >
> > >
> ./systests/protocol-tests-amqp-1-0/target/surefire-reports/java-mms.1-0/TEST-org.apache.qpid.tests.protocol.v1_0.transport.connection.OpenTest.failOpenOnNonExistingHostname.txt,
> > > > could you please send it over?
> > >
> > > Attached
> > >
> > > -
> > > 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.0.8

[Rob Godfrey]

On Fri, 5 Jul 2019 at 12:19, Oleksandr Rudyy  wrote:

> Hi Rob,
>
> Thanks for confirmation.
> I will port QPID-8150 changes into the 7.0.x branch. Somehow, I missed to
> merge them into 7.0 :(
>
>
I certainly don't think it is a blocker for this release, the test
"failure" is simply down to how long (failed) dns resolution takes on the
machine running the test.

-- Rob


> Kind Regards,
> Alex
>
> On Fri, 5 Jul 2019 at 11:16, Rob Godfrey  wrote:
>
> > Hi Alex,
> >
> > thanks for finding that JIRA for me - I knew that I'd fixed this at some
> > point in the past.
> >
> > Just to confirm that that fixes the test for me.  So I'm +1 on the
> release
> > (perhaps we should apply that fix to the 7.0.x branch in case we do any
> > more releases from there)
> >
> > Build from src, ran tests (passing with the fix to the test configuration
> > applied)
> > Started the broker and tested the web console.
> >
> > -- Rob
> >
> >
> > On Fri, 5 Jul 2019 at 12:09, Oleksandr Rudyy  wrote:
> >
> > > Gordon,
> > >
> > > Thanks for the logs. Though, there is nothing interesting there which
> > would
> > > shed light over the failure cause.
> > >
> > > The log file contain a record for receiving OPEN performative, and,
> after
> > > that, in 6 seconds the test fails.
> > >
> > > Rob reported QPID-8150 [1] about issues with time taken by hostname
> > > resolution. There are port host aliases configured in broker
> > configuration
> > > which are resolving host names. On some environments it take a lot of
> > time.
> > >   It could be potential reason for the test failure.
> > >
> > > What is your environment?
> > >
> > > You can remove the hostname alias entry from the broker test
> > configuration
> > > to make sure that it does not impact the test.
> > >
> > > The diff is below
> > >
> > > $ git diff
> > > diff --git
> > >
> > >
> >
> a/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> > >
> > >
> >
> b/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> > > index 764ff891a..522fd5bea 100644
> > > ---
> > >
> > >
> >
> a/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> > > +++
> > >
> > >
> >
> b/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> > > @@ -47,9 +47,6 @@
> > >  "virtualhostaliases" : [ {
> > >"name" : "defaultAlias",
> > >"type" : "defaultAlias"
> > > -}, {
> > > -  "name" : "hostnameAlias",
> > > -  "type" : "hostnameAlias"
> > >  }, {
> > >"name" : "nameAlias",
> > >"type" : "nameAlias"
> > > @@ -64,10 +61,6 @@
> > >"name" : "defaultAlias",
> > >"type" : "defaultAlias",
> > >"durable" : true
> > > -}, {
> > > -  "name" : "hostnameAlias",
> > > -  "type" : "hostnameAlias",
> > > -  "durable" : true
> > >  }, {
> > >"name" : "nameAlias",
> > >"type" : "nameAlias",
> > >
> > >
> > > I hope that the above should fix the issue.
> > >
> > > Kind Regards,
> > > Alex
> > >
> > > [1] https://issues.apache.org/jira/browse/QPID-8150
> > >
> > >
> > > On Fri, 5 Jul 2019 at 09:54, Gordon Sim  wrote:
> > >
> > > > On 05/07/2019 9:26 am, Oleksandr Rudyy wrote:
> > > > > Hi Gordon,
> > > > >
> > > > > Thanks for testing the release and reporting a test failure.
> > > > >
> > > > > The failed test sends open performative against non existing
> virtual
> > > host
> > > > > and expects to receive an "open" back containing an error
> > > > "amqp:not-found"
> > > > > within 6 seconds after sending "open".
> > > > > The failure occurred because "open" was not received within 6
> > seconds.
> > > It
> > > > > could be environmental. For example, a long GC "stop the world"
> pause
> > > can
> > > > > cause it, or, environment in use could be slow.
> > > >
> > > > I did run all the tests a second time and again it failed on that
> > > > specific test only. (Not that that necessarily rules out your
> > hypothesis)
> > > >
> > > > > The test logs could provide more details about test execution.
> > > > >
> > > > > If you still have a test log file
> > > > >
> > > >
> > >
> >
> ./systests/protocol-tests-amqp-1-0/target/surefire-reports/java-mms.1-0/TEST-org.apache.qpid.tests.protocol.v1_0.transport.connection.OpenTest.failOpenOnNonExistingHostname.txt,
> > > > > could you please send it over?
> > > >
> > > > Attached
> > > >
> > > > -
> > > > 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.0.8

[Rob Godfrey]

Hi Alex,

thanks for finding that JIRA for me - I knew that I'd fixed this at some
point in the past.

Just to confirm that that fixes the test for me.  So I'm +1 on the release
(perhaps we should apply that fix to the 7.0.x branch in case we do any
more releases from there)

Build from src, ran tests (passing with the fix to the test configuration
applied)
Started the broker and tested the web console.

-- Rob


On Fri, 5 Jul 2019 at 12:09, Oleksandr Rudyy  wrote:

> Gordon,
>
> Thanks for the logs. Though, there is nothing interesting there which would
> shed light over the failure cause.
>
> The log file contain a record for receiving OPEN performative, and, after
> that, in 6 seconds the test fails.
>
> Rob reported QPID-8150 [1] about issues with time taken by hostname
> resolution. There are port host aliases configured in broker configuration
> which are resolving host names. On some environments it take a lot of time.
>   It could be potential reason for the test failure.
>
> What is your environment?
>
> You can remove the hostname alias entry from the broker test configuration
> to make sure that it does not impact the test.
>
> The diff is below
>
> $ git diff
> diff --git
>
> a/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
>
> b/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> index 764ff891a..522fd5bea 100644
> ---
>
> a/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> +++
>
> b/systests/protocol-tests-amqp-1-0/src/main/resources/config-protocol-tests.json
> @@ -47,9 +47,6 @@
>  "virtualhostaliases" : [ {
>"name" : "defaultAlias",
>"type" : "defaultAlias"
> -}, {
> -  "name" : "hostnameAlias",
> -  "type" : "hostnameAlias"
>  }, {
>"name" : "nameAlias",
>"type" : "nameAlias"
> @@ -64,10 +61,6 @@
>"name" : "defaultAlias",
>"type" : "defaultAlias",
>"durable" : true
> -}, {
> -  "name" : "hostnameAlias",
> -  "type" : "hostnameAlias",
> -  "durable" : true
>  }, {
>"name" : "nameAlias",
>"type" : "nameAlias",
>
>
> I hope that the above should fix the issue.
>
> Kind Regards,
> Alex
>
> [1] https://issues.apache.org/jira/browse/QPID-8150
>
>
> On Fri, 5 Jul 2019 at 09:54, Gordon Sim  wrote:
>
> > On 05/07/2019 9:26 am, Oleksandr Rudyy wrote:
> > > Hi Gordon,
> > >
> > > Thanks for testing the release and reporting a test failure.
> > >
> > > The failed test sends open performative against non existing virtual
> host
> > > and expects to receive an "open" back containing an error
> > "amqp:not-found"
> > > within 6 seconds after sending "open".
> > > The failure occurred because "open" was not received within 6 seconds.
> It
> > > could be environmental. For example, a long GC "stop the world" pause
> can
> > > cause it, or, environment in use could be slow.
> >
> > I did run all the tests a second time and again it failed on that
> > specific test only. (Not that that necessarily rules out your hypothesis)
> >
> > > The test logs could provide more details about test execution.
> > >
> > > If you still have a test log file
> > >
> >
> ./systests/protocol-tests-amqp-1-0/target/surefire-reports/java-mms.1-0/TEST-org.apache.qpid.tests.protocol.v1_0.transport.connection.OpenTest.failOpenOnNonExistingHostname.txt,
> > > could you please send it over?
> >
> > Attached
> >
> > -
> > 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.0.8

[Rob Godfrey]

On Fri, 5 Jul 2019 at 10:54, Gordon Sim  wrote:

> On 05/07/2019 9:26 am, Oleksandr Rudyy wrote:
> > Hi Gordon,
> >
> > Thanks for testing the release and reporting a test failure.
> >
> > The failed test sends open performative against non existing virtual host
> > and expects to receive an "open" back containing an error
> "amqp:not-found"
> > within 6 seconds after sending "open".
> > The failure occurred because "open" was not received within 6 seconds. It
> > could be environmental. For example, a long GC "stop the world" pause can
> > cause it, or, environment in use could be slow.
>
> I did run all the tests a second time and again it failed on that
> specific test only. (Not that that necessarily rules out your hypothesis)
>

I am also seeing this error on this test (MacOs 10.14 Mojave, jdk 1.8.0_74)

-- Rob


>
> > The test logs could provide more details about test execution.
> >
> > If you still have a test log file
> >
> ./systests/protocol-tests-amqp-1-0/target/surefire-reports/java-mms.1-0/TEST-org.apache.qpid.tests.protocol.v1_0.transport.connection.OpenTest.failOpenOnNonExistingHostname.txt,
> > could you please send it over?
>
> Attached
>
> -
> 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.4

[Rob Godfrey]

On Wed, 3 Jul 2019 at 14:53, Alex Rudyy  wrote:

> Hi folks,
>
> I built release artefacts for Qpid Broker-J version 7.1.4 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.4-rc1/
>
>
+1 Built and ran tests / integration tests (JDK 8 on Mac)
Started the broker and kicked the tyres of the web console

-- Rob


> The maven artifacts are also staged at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1179
>
> 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=12345532
>
> 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-1179
> 
> 
> 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

Re: Negative Bytes Credit

[Rob Godfrey]

Alex,

looks like a broker defect to me.  If the bytes (or message) credit is set
to "infinite credit", then the useCreditForMessage method won't update the
used bytes (or message) credit.  However the restoreCredit method always
tries to deduct from the bytes (or message) used value, which will lead to
this error.  Since the default for the JMS client is (IIRC) an infinite
bytes credit paired with a fixed amount of message credit then we will see
this error.  Ironically it is being seen in 7.0.7 because we fixed a real
bug in 7.0.6 (https://issues.apache.org/jira/browse/QPID-8225).  The
"error" observed by Sirdath here is (as you say elsewhere) completely
harmless and can be ignored.

-- Rob

On Wed, 12 Jun 2019 at 11:52, Oleksandr Rudyy  wrote:

> Sidarth,
>
> I cannot see any negative effect from the error at the moment. I believe
> that WARN log level should be used to report the issue like this one.
> Though, it is unclear for me yet whether it is a client or broker defect.
>
> Kind Regards,
> Alex
>
>
> On Tue, 11 Jun 2019 at 23:50, sidarthsc 
> wrote:
>
> > I will try to get that information to you asap. Do you know if this error
> > messages signifies something impactful? Functionally, the broker appears
> to
> > be doing fine. Our throughput has not not decreased and most vitals, e.g.
> > heap memory, look okay.
> >
> >
> >
> > --
> > 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
> >
> >
>

Re: Microservices Exchange Queue Strategy

[Rob Godfrey]

Hi,

On Wed, 12 Jun 2019 at 09:55, fea17e86  wrote:

> Hi
>
> I want to use Qpid Broker-J and AMQP 1.0 to achieve and event and message
> based communication between my microservices. I would like to hear your
> thoughts on the following scenario:
>
> There are one or more microservices subscribing to the same topic. All of
> the subscribers should receive all messages, or at least the last message
> of
> the same value (LVQ). Even if a subscriber was offline, due to updates,
> failures, or whatever, it should always receive the messages, once being
> online again.
>
> I thought I need to create a topic exchange and create one LVQ per
> subscriber, to make sure that each one of them gets the same messages. Is
> that correct, is there a more elegant way then creating n queues?
>

So, firstly, if you want all the messages to go to all the queues, you can
use a fanout exchange rather than a topic exchange.

In terms of alternative ways to implement the pattern... the way you
describe is probably what you need if you want to ensure that reconnecting
clients only receive messages that they haven't seen before when they were
previously connected.  If  it is OK that on reconnection the client
receives the latest value for every key (whether they have seen it before
or not) then you could use a single LVQ (rather than one per client) and
set the "ensureNonDestructiveConsumers" property to true.

-- Rob


>
> Best regards
> fea
>
>
>
> --
> 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
>
>

Re: Broker-J topic example with rhea.js

[Rob Godfrey]

On Fri, 7 Jun 2019 at 16:24, fea17e86  wrote:

> Hi,
>
> I'm trying to get a publish subscribe example with Broker-J and  rhea.js
>    to work.
>
> First I created a few queues bound to the default exchange "amq.topic":
>
> 
>
> Then I created a publisher with rhea.js: https://pastebin.com/4MWe1Qgh it
> is
> a modified version of the rhea.js  publisher
> <
> https://github.com/amqp/rhea/blob/master/examples/durable_subscription/publisher.js>
>
> and  subscriber
> <
> https://github.com/amqp/rhea/blob/master/examples/durable_subscription/subscriber.js>
>
> example.
>
> Unfortunately it doesn't work, a Could not find destination for target
> 'Target{address=objects.bed.update,durable=none}' error is thrown:
> https://pastebin.com/AifSYHGs
>
> Can anybody please help me with figuring out which host name and topic name
> to use? Any help would be appreaciated!
>
> Best regards
> Tobi
>
>
"objects.bed.update" is a binding to amq.topic, it is not an an address in
itself.

You should be able to send to the address "amq.topic/objects.bed.update"
(i.e. /) to achieve what you want

-- Rob


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

Re: Qpid Broker-J - Add a certificate without recreating an SSL port

[Rob Godfrey]

I believe you can use the ManagedPeerCertificateTrustStore if you want to
dynamically add and remove certificates in this way.  Having the broker
reload a JKS store would require a change.

-- Rob

On Mon, 8 Apr 2019 at 13:26, Tomas Soltys  wrote:

> Hi,
>
> After I add a user certificate to a truststore (JKS) it seems like I need
> to
> either restart a broker or recreate an SSL port in order to be able to
> authenticate. Side effect of this is loosing all active connections on that
> port.
> Is there a way to "reinitialize" the port in such way so other live
> connections are not lost?
>
> Thanks,
> 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
>
>

Re: [VOTE] Release Qpid Broker-J 7.1.2

[Rob Godfrey]

+1

built and ran tests (0-9-1 and 1.0)
ad-hoc testing via the web console

On Wed, 3 Apr 2019 at 16:15, Robbie Gemmell 
wrote:

> On Sun, 31 Mar 2019 at 14:36, Oleksandr Rudyy  wrote:
> >
> > Hi,
> >
> > I built release artefacts for Qpid Broker-J version 7.1.2 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.2-rc1/
> >
> > The maven artifacts are also staged at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1170
> >
> > The new version incorporates improvement for priority queues allowing to
> > change message priorities. You can find the full list of JIRAs included
> > into the release here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520=12345042
> >
> > 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-1170
> 
> > 
> > 
> >
>
> +1
>
> I checked things over as follows:
> - Verified all the signature and checksum files.
> - Ran "mvn apache-rat:check" to verify headers in the source archive.
> - Checked for LICENCE and NOTICE files being present in the archives.
> - Ran the build and tests with "mvn clean verify -DskipITs=false".
> - Started broker from binary 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
>
>

Re: [VOTE] Release Qpid Broker-J 7.1.1

[Rob Godfrey]

+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
>
>

Re: [VOTE] Release Qpid Broker-J 7.0.7

[Rob Godfrey]

+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:14, Gordon Sim  wrote:

> On 25/02/2019 3:31 pm, Alex Rudyy wrote:
> > Hi,
> >
> > I built release artefacts for Qpid Broker-J version 7.0.7 RC1.
> > Please, give them 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.7-rc1/
> >
> > The maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1168
> >
> > The new versions comes with 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=12343590
>
> +1, verified signature and checksum, built from source, ran tests
> (reported failures not problematic for release as detailed by Rob), ran
> python examples against broker
>
> -
> 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

[Rob Godfrey]

Agreed - I don't think this is a blocker for this release... the "issue",
such as it is, is an insecure self signed certificate in the test code...
which obviously is of no importance.

-- Rob

On Tue, 26 Feb 2019 at 13:40, Oleksandr Rudyy  wrote:

> Hm...
>
> The build passes for me on Fedora 27 with OpenJDK 1.8.0_191.
> It seems that some TLS related algorithms have been disabled in OpenJDK
> 8u201.
> This version of JDK is not available on Fedora 27. I need to upgrade my OS
> or find another version of JDK failing with the same symptoms.
> 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.
>
> I will look into fixing this issue tonight.
>
> Kind Regards,
> Alex
>
>
> On Tue, 26 Feb 2019 at 11:16, Rob Godfrey  wrote:
>
> > So, I think this is an OpenJDK vs. Oracle JDK problem.  Running install
> > 7.1.0 on OpenJDK (8u201) also fails on my Fedora machine.  Switching to
> the
> > Oracle JDK and it installs fine.
> >
> > -- Rob
> >
> > On Tue, 26 Feb 2019 at 11:46, Rob Godfrey 
> wrote:
> >
> > >
> > >
> > > On Tue, 26 Feb 2019 at 11:04, Gordon Sim  wrote:
> > >
> > >> On 25/02/2019 1:22 pm, Oleksandr Rudyy wrote:
> > >> > Hi folks,
> > >> >
> > >> > I built release artefacts for Qpid Broker-J version 7.1.1 RC1.
> > >> > Please, give them 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.1.1-rc1/
> > >> >
> > >> > The maven artifacts are also staged for now at:
> > >> >
> https://repository.apache.org/content/repositories/orgapacheqpid-1167
> > >> >
> > >> > The new versions comes with 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=12344881
> > >>
> > >> I'm seeing errors when trying to run `mvn clean install`:
> > >>
> > >> > [INFO] Results:
> > >> > [INFO]
> > >> > [ERROR] Failures:
> > >> > [ERROR]
> > >>
> >
> OAuth2AuthenticationProviderImplTest.testAuthenticateViaAccessToken:236->assertSuccess:255
> > >> Authentication was not successful:
> javax.net.ssl.SSLHandshakeException:
> > >> java.security.cert.CertificateException: Certificates do not conform
> to
> > >> algorithm constraints expected: but was:
> > >> > [ERROR]
> > >>
> >
> OAuth2AuthenticationProviderImplTest.testAuthenticateViaAuthorizationCode:205->assertSuccess:255
> > >> Authentication was not successful:
> javax.net.ssl.SSLHandshakeException:
> > >> java.security.cert.CertificateException: Certificates do not conform
> to
> > >> algorithm constraints expected: but was:
> > >> > [ERROR]
> > >>
> >
> OAuth2AuthenticationProviderImplTest.testAuthenticateViaSasl:174->assertSuccess:255
> > >> Authentication was not successful:
> javax.net.ssl.SSLHandshakeException:
> > >> java.security.cert.CertificateException: Certificates do not conform
> to
> > >> algorithm constraints expected: but was:
> > >> > [ERROR]
> > >>
> >
> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaInvalidAccessToken:250->assertFailure:268
> > >> javax.net.ssl.SSLHandshakeException:
> > >> java.security.cert.CertificateException: Certificates do not conform
> to
> > >> algorithm constraints
> > >> > [ERROR]
> > >>
> >
> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaInvalidAuthorizationCode:225->assertFailure:268
> > >> javax.net.ssl.SSLHandshakeException:
> > >> java.security.cert.CertificateException: Certificates do not conform
> to
> > >> algorithm constraints
> > >> > [ERROR]
> > >>
> >
> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaSasl:188->assertFailure:268
> > >> javax.net.ssl.SSLHandshakeException:
> > >> java.security.cert.CertificateException: Certificates do not conform
> to
> > >> algorithm constraints
> > >> > [ERROR]
> > >>
> TrustManagerTest.testQpidMultipleTrustManagerWithRe

Re: [VOTE] Release Qpid Broker-J 7.1.1

[Rob Godfrey]

So, I think this is an OpenJDK vs. Oracle JDK problem.  Running install
7.1.0 on OpenJDK (8u201) also fails on my Fedora machine.  Switching to the
Oracle JDK and it installs fine.

-- Rob

On Tue, 26 Feb 2019 at 11:46, Rob Godfrey  wrote:

>
>
> On Tue, 26 Feb 2019 at 11:04, Gordon Sim  wrote:
>
>> On 25/02/2019 1:22 pm, Oleksandr Rudyy wrote:
>> > Hi folks,
>> >
>> > I built release artefacts for Qpid Broker-J version 7.1.1 RC1.
>> > Please, give them 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.1.1-rc1/
>> >
>> > The maven artifacts are also staged for now at:
>> > https://repository.apache.org/content/repositories/orgapacheqpid-1167
>> >
>> > The new versions comes with 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=12344881
>>
>> I'm seeing errors when trying to run `mvn clean install`:
>>
>> > [INFO] Results:
>> > [INFO]
>> > [ERROR] Failures:
>> > [ERROR]
>>  
>> OAuth2AuthenticationProviderImplTest.testAuthenticateViaAccessToken:236->assertSuccess:255
>> Authentication was not successful: javax.net.ssl.SSLHandshakeException:
>> java.security.cert.CertificateException: Certificates do not conform to
>> algorithm constraints expected: but was:
>> > [ERROR]
>>  
>> OAuth2AuthenticationProviderImplTest.testAuthenticateViaAuthorizationCode:205->assertSuccess:255
>> Authentication was not successful: javax.net.ssl.SSLHandshakeException:
>> java.security.cert.CertificateException: Certificates do not conform to
>> algorithm constraints expected: but was:
>> > [ERROR]
>>  
>> OAuth2AuthenticationProviderImplTest.testAuthenticateViaSasl:174->assertSuccess:255
>> Authentication was not successful: javax.net.ssl.SSLHandshakeException:
>> java.security.cert.CertificateException: Certificates do not conform to
>> algorithm constraints expected: but was:
>> > [ERROR]
>>  
>> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaInvalidAccessToken:250->assertFailure:268
>> javax.net.ssl.SSLHandshakeException:
>> java.security.cert.CertificateException: Certificates do not conform to
>> algorithm constraints
>> > [ERROR]
>>  
>> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaInvalidAuthorizationCode:225->assertFailure:268
>> javax.net.ssl.SSLHandshakeException:
>> java.security.cert.CertificateException: Certificates do not conform to
>> algorithm constraints
>> > [ERROR]
>>  
>> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaSasl:188->assertFailure:268
>> javax.net.ssl.SSLHandshakeException:
>> java.security.cert.CertificateException: Certificates do not conform to
>> algorithm constraints
>> > [ERROR]
>>  TrustManagerTest.testQpidMultipleTrustManagerWithRegularTrustStore:193
>> Trusted client's validation against the broker's multi store manager failed.
>> > [ERROR]
>>  TrustManagerTest.testQpidMultipleTrustManagerWithTrustAndPeerStores:340
>> Trusted client's validation against the broker's multi store manager failed.
>> > [ERROR] Errors:
>> > [ERROR]   SiteSpecificTrustStoreTest.testRefreshCertificate »
>> IllegalConfiguration Unabl...
>> > [ERROR]   SiteSpecificTrustStoreTest.testValidSiteUrl »
>> IllegalConfiguration Unable to g...
>> > [INFO]
>> > [ERROR] Tests run: 1324, Failures: 8, Errors: 2, Skipped: 7
>>
>> Not sure if this is some environmental issue on my side? or missing setup?
>>
>
> I see the same errors when running on Fedora 29, however the tests run
> fine on my Mac (OS X 10.14)
>
> -- Rob
>
>
>>
>> -
>> 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

[Rob Godfrey]

On Tue, 26 Feb 2019 at 11:04, Gordon Sim  wrote:

> On 25/02/2019 1:22 pm, Oleksandr Rudyy wrote:
> > Hi folks,
> >
> > I built release artefacts for Qpid Broker-J version 7.1.1 RC1.
> > Please, give them 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.1.1-rc1/
> >
> > The maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1167
> >
> > The new versions comes with 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=12344881
>
> I'm seeing errors when trying to run `mvn clean install`:
>
> > [INFO] Results:
> > [INFO]
> > [ERROR] Failures:
> > [ERROR]
>  
> OAuth2AuthenticationProviderImplTest.testAuthenticateViaAccessToken:236->assertSuccess:255
> Authentication was not successful: javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: Certificates do not conform to
> algorithm constraints expected: but was:
> > [ERROR]
>  
> OAuth2AuthenticationProviderImplTest.testAuthenticateViaAuthorizationCode:205->assertSuccess:255
> Authentication was not successful: javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: Certificates do not conform to
> algorithm constraints expected: but was:
> > [ERROR]
>  
> OAuth2AuthenticationProviderImplTest.testAuthenticateViaSasl:174->assertSuccess:255
> Authentication was not successful: javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: Certificates do not conform to
> algorithm constraints expected: but was:
> > [ERROR]
>  
> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaInvalidAccessToken:250->assertFailure:268
> javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: Certificates do not conform to
> algorithm constraints
> > [ERROR]
>  
> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaInvalidAuthorizationCode:225->assertFailure:268
> javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: Certificates do not conform to
> algorithm constraints
> > [ERROR]
>  
> OAuth2AuthenticationProviderImplTest.testFailAuthenticateViaSasl:188->assertFailure:268
> javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: Certificates do not conform to
> algorithm constraints
> > [ERROR]
>  TrustManagerTest.testQpidMultipleTrustManagerWithRegularTrustStore:193
> Trusted client's validation against the broker's multi store manager failed.
> > [ERROR]
>  TrustManagerTest.testQpidMultipleTrustManagerWithTrustAndPeerStores:340
> Trusted client's validation against the broker's multi store manager failed.
> > [ERROR] Errors:
> > [ERROR]   SiteSpecificTrustStoreTest.testRefreshCertificate »
> IllegalConfiguration Unabl...
> > [ERROR]   SiteSpecificTrustStoreTest.testValidSiteUrl »
> IllegalConfiguration Unable to g...
> > [INFO]
> > [ERROR] Tests run: 1324, Failures: 8, Errors: 2, Skipped: 7
>
> Not sure if this is some environmental issue on my side? or missing setup?
>

I see the same errors when running on Fedora 29, however the tests run fine
on my Mac (OS X 10.14)

-- Rob


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

Re: Rollback Failure

[Rob Godfrey]

On Thu, 31 Jan 2019 at 19:02, sidarthsc 
wrote:

> Thanks Rob! That makes sense. Similarly, we're seeing a lot of exceptions
> of
> the form "Session sync was interrupted by failover. [error code 541:
> internal error]." Unfortunately, I'm not seeing in anything in the broker
> logs and we're logging at the "INFO" level.
>

I think this is likely similar in nature.  "interrupted by failover" means
(IIRC) that the connection was closed and the client is trying to
reestablish, but at the time the client was waiting for a synchronization
over the wire, that was never completed.  Have you turned on verbose gc
logging for the broker?  My best guess would still be excessive GC pauses.

-- Rob


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

Re: QPID feature to synchronize messages

[Rob Godfrey]

In the docs:

https://qpid.apache.org/releases/qpid-broker-j-7.1.0/book/Java-Broker-Concepts-Queues.html#Java-Broker-Concepts-Queue-HoldingEntries

describes how messages an be "held"

https://qpid.apache.org/releases/qpid-broker-j-7.1.0/book/Java-Broker-Concepts-Queues.html#Java-Broker-Concepts-Queues-Types-Sorted

briefly describes the Sorted queue type  (note that you can't sort on
message id directly as that is not a custom property of type String - you
would need to add an application property to your messages which is a
String and will sort the way you want - e.g. if numeric you would need to
add leading zeros to pad the String so it sorts the way you want).

-- Rob

On Wed, 30 Jan 2019 at 18:04, Bee k  wrote:

> Thank you.  I will look into that.
>
>
> > On Jan 30, 2019, at 4:20 AM, Rob Godfrey 
> wrote:
> >
> >> On Wed, 30 Jan 2019, 12:39 Gordon Sim  >>
> >>> On 30/01/19 10:31, Rob Godfrey wrote:
> >>> Actually Qpid Broker-J does support both holding messages for a given
> >> time
> >>> before delivery, and sorted queues (i.e. ordering the delivery of
> >> messages
> >>> from a particular queue based on a header value).
> >>
> >> Sorry, did not know that!
> >>
> >
> > It's not a feature that I see used often, and has some impact on
> > performance for that queue because queue entry/exit has to be
> synchronised.
> >
> > -- 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
>
>

Re: QPID feature to synchronize messages

[Rob Godfrey]

Actually Qpid Broker-J does support both holding messages for a given time
before delivery, and sorted queues (i.e. ordering the delivery of messages
from a particular queue based on a header value).

-- Rob

On Wed, 30 Jan 2019 at 10:20, Gordon Sim  wrote:

> On 29/01/19 16:46, Bee k wrote:
> > Does QPID have feature to hold incoming messages for certain duration
> and sort them out by a value in the content (i.e. message ID) before
> publishing the messages?
>
> No
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Rollback Failure

[Rob Godfrey]

On Fri, 18 Jan 2019 at 00:38, sidarthsc 
wrote:

> Our server is running broker-j 7.0.6 and our sessions are transacted. We're
> seeing a lot of exceptions of the form "Failed to rollback:
> org.apache.qpid.AMQException: timed out waiting for sync: complete = 18,
> point = 19 [error code 541: internal error]" I read that this can be a
> symptom of the broker being overloaded. Any ideas other relieving pressure
> on the broker and increasing the value of sync_op_timeout? Also, we're
> using
> a much older version of the client, but are currently upgrading to
> jms-amqp-0-x 6.3.3. Thanks!
>
>
>
I think you pretty much covered it already...  One common cause of these
sort of timeouts can be long garbage collection pauses in the Broker - do
you have any monitoring in place on the broker to see what it is doing
during these periods?  Even if it is "heavily loaded" it still shouldn't
really timeout unless you are seeing GC pauses, swapping to disk, or some
other similar condition.  The timeout is already sufficiently high that
raising it really doesn't help much IMHO.

-- Rob


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

Re: Can I expose Java properties set in the Qpid broker server via JMX or the REST API?

[Rob Godfrey]

Hi Brian,

On Wed, 19 Dec 2018 at 23:18, Brian O'Shea  wrote:

> Looking at jconsole (connected to the running Qpid broker), it appears that
> it exposes a Map under java.lang -> Runtime -> Attributes
> ->
> SystemProperties.  Is this something that I can depend on always being
> available?  This is Qpid version 7.0.6, which no longer supports management
> over JMX, but will this attribute always be accessible over JMX?
>
>
These JMX attributes are expose by the Java Runtime itself rather than
being in any way tied to Qpid.  As such I believe you can rely on their
availability.

-- Rob



> Thanks,
> Brian O'Shea
> Salesforce
>
>
>
> --
> 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
>
>

Re: [Java Broker] Connection to broker using public key of certification authority in broker truststore

[Rob Godfrey]

On Wed, 12 Dec 2018 at 16:13, Vavricka  wrote:

> Hi,
>
> I tried to authenticate via certificate which is signed by my own
> certificate authority and only certificate authority public key is present
> in broker.
>
> Steps I have done:
> * create certificate authority
> * add public CA key to broker truststore (certutil DB in C++ broker)
> * sign client private key by CA
> * use signed private certificate in client to connect to broker
>
> When I perform steps above I am able to connect to C++ broker if only
> public
> CA key is present in broker certificate DB. When I used same steps on Java
> Broker I get exception 'javax.net.ssl.SSLException: Received fatal alert:
> certificate_unknown'.
>
> Am I doing something wrong?
>
> Does Java Broker supports this feature?
>
>
Broker-J supports client authentication using certificates and there are
tests for this functionality.  What is the configuration you have used for
the port/truststore on the (Java) Broker?  Have you checked your jks? store
to make sure the certificates were imported correctly?

-- Rob


> qpid-cpp version 1.36.0
> Java Broker version 7.0.4
>
> 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
>
>

Re: [NOTICE / DISCUSS] migrating Git repositories to gitbox.apache.org

[Rob Godfrey]

On Mon, 10 Dec 2018 at 17:10, Robbie Gemmell 
wrote:

> Hi Folks,
>
> Per the below mail sent by the ASF Infrastructure team (to dev@), our Git
> repositories will be migrated from the original/old git-wip-us service on
> to
> the newer gitbox.apache.org service by February 7th.
>
> This is definitely happening, but we have some say over when/how it does:
> 1. Document consensus on list and voluntarily request to move by Jan 9th.
> 2. Wait for mandated move between Jan 9th and Feb 6th, coordinate with
> infra
>to proceed once it has been.
> 3. Do nothing, ignore the mandate, and be forcibly moved on Feb 7th.
>
> I'm in favour of volunteering and doing it sooner than later, so to
> that end here is my lazy consensus statement:
>
> Unless there is discussion here resulting in decision to delay, I will
> raise the migration request JIRA with Infra on Thursday 13th Dec,
> hopefully allowing completion of the process by the end of this week
> if they have bandwidth to do so.
>
> Robbie
>

Not that it is required for a lazy consensus, but I am +1 on "sooner" :)

-- Rob


>
> On Fri, 7 Dec 2018 at 16:52, Daniel Gruno wrote:
> >
> > [NOTICE] Mandatory relocation of Apache git repositories on
> git-wip-us.apache.org
> >
> >
> > [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
> >   DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
> >
> > Hello Apache projects,
> >
> > I am writing to you because you may have git repositories on the
> > git-wip-us server, which is slated to be decommissioned in the coming
> > months. All repositories will be moved to the new gitbox service which
> > includes direct write access on github as well as the standard ASF
> > commit access via gitbox.apache.org.
> >
> > ## Why this move? ##
> > The move comes as a result of retiring the git-wip service, as the
> > hardware it runs on is longing for retirement. In lieu of this, we
> > have decided to consolidate the two services (git-wip and gitbox), to
> > ease the management of our repository systems and future-proof the
> > underlying hardware. The move is fully automated, and ideally, nothing
> > will change in your workflow other than added features and access to
> > GitHub.
> >
> > ## Timeframe for relocation ##
> > Initially, we are asking that projects voluntarily request to move
> > their repositories to gitbox, hence this email. The voluntary
> > timeframe is between now and January 9th 2019, during which projects
> > are free to either move over to gitbox or stay put on git-wip. After
> > this phase, we will be requiring the remaining projects to move within
> > one month, after which we will move the remaining projects over.
> >
> > To have your project moved in this initial phase, you will need:
> >
> > - Consensus in the project (documented via the mailing list)
> > - File a JIRA ticket with INFRA to voluntarily move your project repos
> >over to gitbox (as stated, this is highly automated and will take
> >between a minute and an hour, depending on the size and number of
> >your repositories)
> >
> > To sum up the preliminary timeline;
> >
> > - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
> >relocation
> > - January 9th -> February 6th: Mandated (coordinated) relocation
> > - February 7th: All remaining repositories are mass migrated.
> >
> > This timeline may change to accommodate various scenarios.
> >
> > ## Using GitHub with ASF repositories ##
> > When your project has moved, you are free to use either the ASF
> > repository system (gitbox.apache.org) OR GitHub for your development
> > and code pushes. To be able to use GitHub, please follow the primer
> > at: https://reference.apache.org/committer/github
> >
> >
> > We appreciate your understanding of this issue, and hope that your
> > project can coordinate voluntarily moving your repositories in a
> > timely manner.
> >
> > All settings, such as commit mail targets, issue linking, PR
> > notification schemes etc will automatically be migrated to gitbox as
> > well.
> >
> > With regards, Daniel on behalf of ASF Infra.
> >
> > PS:For inquiries, please reply to us...@infra.apache.org, not your
> > project's dev list :-).
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: Welcome Roddie Kieley as an Apache Qpid committer

[Rob Godfrey]

Welcome Roddie - good to have you here!

-- Rob

On Tue, 27 Nov 2018 at 17:18, Oleksandr Rudyy  wrote:

> Welcome, Roddie!
> On Tue, 27 Nov 2018 at 14:38, Robbie Gemmell 
> wrote:
> >
> > The Qpid PMC have voted to grant commit rights to Roddie Kieley in
> > recognition of continued contributions to the project.
> >
> > Welcome, Roddie!
> >
> > 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] JDBC config store

[Rob Godfrey]

Actually, ignore that too... Been too long since I looked at this code.

There doesn't actually seem to be any way to set an arbitrary property in
the system config. :-(

This seems like something we should raise an enhancement for

Apologies,
Rob

On Mon, 26 Nov 2018 at 18:02, Rob Godfrey  wrote:

> D'Oh again you are completely correct, apologies...this is at the system
> config level not broker...
>
> So the only way to pass it in is as a command line parameter -prop
> 'preferenceStoreAttributes=...'
>
> -- Rob
>
>
>
> On Mon, 26 Nov 2018 at 17:55, VERMEULEN Olivier <
> olivier.vermeu...@murex.com> wrote:
>
>> Actually, looking at the code, there is no 'preferenceStoreAttributes'
>> field in the Broker class
>>
>> https://github.com/apache/qpid-broker-j/blob/c018e1ac9d21e9f5eb38d2ae7a26a31e63c07fdf/broker-core/src/main/java/org/apache/qpid/server/model/Broker.java
>> So it's expected that it would be ignored in the below config file no?
>>
>> Olivier
>>
>> {
>>   "name": "${broker.name}",
>>   "modelVersion": "7.0",
>>
>>   "preferenceStoreAttributes": {
>> "type" : "Noop"
>>   },
>>
>>   "authenticationproviders" : [ {
>> "name" : "anonymous",
>> "type" : "Anonymous"
>>   } ],
>>
>> ...
>>
>>   "virtualhostnodes" : [ {
>> "name" : "default",
>> "type" : "JSON",
>> "defaultVirtualHostNode" : "true",
>> "virtualHostInitialConfiguration" : "{ \"type\" : \"DERBY\" }"
>>   } ]
>> }
>>
>> -Original Message-
>> From: VERMEULEN Olivier
>> Sent: lundi 26 novembre 2018 13:32
>> To: users@qpid.apache.org
>> Subject: RE: [Broker-J] JDBC config store
>>
>> Thanks Alex for the fix.
>> I tried setting the 'preferenceStoreAttributes' in the initial
>> configuration but it's not taken into account...
>>
>> Olivier
>>
>> -Original Message-
>> From: Oleksandr Rudyy 
>> Sent: vendredi 23 novembre 2018 12:44
>> To: users@qpid.apache.org
>> Subject: Re: [Broker-J] JDBC config store
>>
>> Hi Olivier,
>>
>> I am sorry for the inconveniences caused  by provided preferences stores
>> configured by default in JDBC system config.
>> I committed  changes against QPID-8260  fixing  the issue with provided
>> preferences stores in DERBY and JDBC system configs.
>>
>> As Rob has suggested already, you can work around the issue by creating
>> your own initial configuration and overriding type of preferences store in
>> attribute 'preferenceStoreAttributes' to  'Noop'
>> or 'JSON'.
>>
>> Kind Regards,
>> Alex
>> On Thu, 22 Nov 2018 at 16:53, Rob Godfrey 
>> wrote:
>> >
>> > On Thu, 22 Nov 2018 at 17:31, VERMEULEN Olivier
>> > 
>> > wrote:
>> >
>> > > Thanks Rob for the answer.
>> > >
>> > > I don't know if I'm looking in the right place but here:
>> > >
>> > > https://github.com/apache/qpid-broker-j/blob/c018e1ac9d21e9f5eb38d2a
>> > > e7a26a31e63c07fdf/broker-plugins/jdbc-store/src/main/java/org/apache
>> > > /qpid/server/store/jdbc/JDBCSystemConfig.java
>> > > the default preference store is "Provided"...
>> > >
>> >
>> > D'oh - I didn't spot that.  That's just a bug, it shouldn't have been
>> > overridden.
>> >
>> >
>> > >
>> > > Do you have a sample where the preferenceStoreAttributes is set?
>> > > I tried in the command line with -prop
>> > > "systemConfig.preferenceStoreAttributes={\"type\":\"Noop\"}
>> > > and in the initial config.json of the broker without any success...
>> > >
>> >
>> > For the initial config.json I would have hoped a top level attribute
>> > preferenceStoreAttributes="{\"type\":\"Noop\", \"attributes\":{}}"
>> > would work... Obviously the initial config will only be picked up if
>> > you are running the broker for the first time pointing at that database
>> instance.
>> >
>> > -- Rob
>> >
>> >
>> > >
>> > > Olivier
>> > >
>> > > -Original Message-
>> > > From: Rob Godfrey 
>> > > 

Re: [Broker-J] JDBC config store

[Rob Godfrey]

D'Oh again you are completely correct, apologies...this is at the system
config level not broker...

So the only way to pass it in is as a command line parameter -prop
'preferenceStoreAttributes=...'

-- Rob



On Mon, 26 Nov 2018 at 17:55, VERMEULEN Olivier 
wrote:

> Actually, looking at the code, there is no 'preferenceStoreAttributes'
> field in the Broker class
>
> https://github.com/apache/qpid-broker-j/blob/c018e1ac9d21e9f5eb38d2ae7a26a31e63c07fdf/broker-core/src/main/java/org/apache/qpid/server/model/Broker.java
> So it's expected that it would be ignored in the below config file no?
>
> Olivier
>
> {
>   "name": "${broker.name}",
>   "modelVersion": "7.0",
>
>   "preferenceStoreAttributes": {
> "type" : "Noop"
>   },
>
>   "authenticationproviders" : [ {
> "name" : "anonymous",
> "type" : "Anonymous"
>   } ],
>
> ...
>
>   "virtualhostnodes" : [ {
> "name" : "default",
> "type" : "JSON",
> "defaultVirtualHostNode" : "true",
> "virtualHostInitialConfiguration" : "{ \"type\" : \"DERBY\" }"
>   } ]
> }
>
> -Original Message-
> From: VERMEULEN Olivier
> Sent: lundi 26 novembre 2018 13:32
> To: users@qpid.apache.org
> Subject: RE: [Broker-J] JDBC config store
>
> Thanks Alex for the fix.
> I tried setting the 'preferenceStoreAttributes' in the initial
> configuration but it's not taken into account...
>
> Olivier
>
> -Original Message-
> From: Oleksandr Rudyy 
> Sent: vendredi 23 novembre 2018 12:44
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] JDBC config store
>
> Hi Olivier,
>
> I am sorry for the inconveniences caused  by provided preferences stores
> configured by default in JDBC system config.
> I committed  changes against QPID-8260  fixing  the issue with provided
> preferences stores in DERBY and JDBC system configs.
>
> As Rob has suggested already, you can work around the issue by creating
> your own initial configuration and overriding type of preferences store in
> attribute 'preferenceStoreAttributes' to  'Noop'
> or 'JSON'.
>
> Kind Regards,
> Alex
> On Thu, 22 Nov 2018 at 16:53, Rob Godfrey  wrote:
> >
> > On Thu, 22 Nov 2018 at 17:31, VERMEULEN Olivier
> > 
> > wrote:
> >
> > > Thanks Rob for the answer.
> > >
> > > I don't know if I'm looking in the right place but here:
> > >
> > > https://github.com/apache/qpid-broker-j/blob/c018e1ac9d21e9f5eb38d2a
> > > e7a26a31e63c07fdf/broker-plugins/jdbc-store/src/main/java/org/apache
> > > /qpid/server/store/jdbc/JDBCSystemConfig.java
> > > the default preference store is "Provided"...
> > >
> >
> > D'oh - I didn't spot that.  That's just a bug, it shouldn't have been
> > overridden.
> >
> >
> > >
> > > Do you have a sample where the preferenceStoreAttributes is set?
> > > I tried in the command line with -prop
> > > "systemConfig.preferenceStoreAttributes={\"type\":\"Noop\"}
> > > and in the initial config.json of the broker without any success...
> > >
> >
> > For the initial config.json I would have hoped a top level attribute
> > preferenceStoreAttributes="{\"type\":\"Noop\", \"attributes\":{}}"
> > would work... Obviously the initial config will only be picked up if
> > you are running the broker for the first time pointing at that database
> instance.
> >
> > -- Rob
> >
> >
> > >
> > > Olivier
> > >
> > > -Original Message-
> > > From: Rob Godfrey 
> > > Sent: jeudi 22 novembre 2018 16:41
> > > To: users@qpid.apache.org
> > > Subject: Re: [Broker-J] JDBC config store
> > >
> > > On Thu, 22 Nov 2018 at 15:11, VERMEULEN Olivier <
> > > olivier.vermeu...@murex.com>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm using version 7.0.3 of the Broker-J.
> > > > I tried to configure it to use a JDBC (here Sybase) config store.
> > > >
> > > > qpid-server.bat -st JDBC -prop
> > > > "systemConfig.connectionUrl=jdbc:sybase:Tds:dell719srv:4100/DB"
> > > > -prop "systemConfig.username=USER" -prop "systemConfig.password=PWD"
> > > >
> > > > But I got the following exception:
> >

Re: Changing system time causes J-Broker to drop connections

[Rob Godfrey]

The connection timeouts are defined by the AMQP protocol and, since in
general the two ends of the connection would be on different machines,
implicitly refer to externally observable time (to the extent that such a
concept is meaningful).

You are changing the literal system time in your system, not just having it
update for daylight saving.  Daylight saving does not change "number of
elapsed milliseconds since the epoch".  Unless your system is suffering
really dreadful drift, regular updates via NTP will not adversely affect
the timeout processing, as the magnitude of any NTP updates should be small
(and connection timeout thresholds should be (relatively) large - certainly
in the order of multiple seconds, not milliseconds).

Admittedly there is a case to be made to switch to System.nanoTime since it
wouldn't be affected by updates to the system time, but then if the updates
are being done by NTP, and your system is so poor at accurate time
measuring that that is making significant updates, it is probably breaking
the AMQP contract for timeouts to use the inaccurate timekeeping of your
machine.  Changing the system time is effectively changing "reality" and
I'm not sure that there is a right or wrong approach here - if you see a
lot of drift and significant updates from NTP I'd just use longer
connection timeouts, or turn them off completely if you want to suspend VMs.

If the broker were dropping connections due to daylight saving times
changes that would definitely be a bug - and I'm pretty confident that on a
correctly set up machine it won't happen... dropping due to changing the
system time is much less clear to me

-- Rob


On Fri, 23 Nov 2018 at 10:32, Sami Siitonen 
wrote:

> I verified that system.currentTimeMillis returns walltime instead of
> monotonic time so it cannot be used to calculate timeouts.
> The problem here concerns every situation where walltime has shifted
> somehow
> and adjusted back, for example when system clock is somehow drifted enough
> and NTP is used to adjust the clock.
> I did a short test program:
>
> import java.text.DateFormat;
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import java.io.Console;
> import java.io.IOException;
> import java.lang.*;
>
> public class JavaTimeTest
> {
> public static void main(String[] args)
> {
> DateFormat dateFormat = new SimpleDateFormat("dd.MM.
> HH:mm:ss");
>
> long currentTimeBefore = System.currentTimeMillis();
> System.out.println("Current time is now: " + currentTimeBefore +
> "ms");
> System.out.println("As DateTime it is: " +
> dateFormat.format(currentTimeBefore));
>
> System.out.println("Change time and press enter to continue...");
> try
> {
> System.in.read();
> }
> catch (IOException e)
> {
> e.printStackTrace();
> }
>
> long currentTimeAfter = System.currentTimeMillis();
> System.out.println("Current time is now: " + currentTimeAfter +
> "ms");
> System.out.println("As DateTime it is: " +
> dateFormat.format(currentTimeAfter));
>
> long timeDiff = currentTimeAfter - currentTimeBefore;
> System.out.println("Difference is: " + timeDiff + "ms");
> }
> }
>
> .. and the printout looks like this when I manually change system time a
> day
> forward:
>
> Current time is now: 1542964907800ms
> As DateTime it is: 23.11.2018 11:21:47
> Change time and press enter to continue...
>
> (...at this point I changed system time manually...)
>
> Current time is now: 1543051313048ms
> As DateTime it is: 24.11.2018 11:21:53
> Difference is: 86405248ms
>
> I hope this clarifies the problem.
>
> --
> Sami
>
>
>
>
> --
> 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
>
>

Re: [Broker-J] JDBC config store

[Rob Godfrey]

On Thu, 22 Nov 2018 at 17:31, VERMEULEN Olivier 
wrote:

> Thanks Rob for the answer.
>
> I don't know if I'm looking in the right place but here:
>
> https://github.com/apache/qpid-broker-j/blob/c018e1ac9d21e9f5eb38d2ae7a26a31e63c07fdf/broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/JDBCSystemConfig.java
> the default preference store is "Provided"...
>

D'oh - I didn't spot that.  That's just a bug, it shouldn't have been
overridden.


>
> Do you have a sample where the preferenceStoreAttributes is set?
> I tried in the command line with -prop
> "systemConfig.preferenceStoreAttributes={\"type\":\"Noop\"}
> and in the initial config.json of the broker without any success...
>

For the initial config.json I would have hoped a top level attribute
preferenceStoreAttributes="{\"type\":\"Noop\", \"attributes\":{}}" would
work... Obviously the initial config will only be picked up if you are
running the broker for the first time pointing at that database instance.

-- Rob


>
> Olivier
>
> -Original Message-
> From: Rob Godfrey 
> Sent: jeudi 22 novembre 2018 16:41
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] JDBC config store
>
> On Thu, 22 Nov 2018 at 15:11, VERMEULEN Olivier <
> olivier.vermeu...@murex.com>
> wrote:
>
> > Hello,
> >
> > I'm using version 7.0.3 of the Broker-J.
> > I tried to configure it to use a JDBC (here Sybase) config store.
> >
> > qpid-server.bat -st JDBC -prop
> > "systemConfig.connectionUrl=jdbc:sybase:Tds:dell719srv:4100/DB" -prop
> > "systemConfig.username=USER" -prop "systemConfig.password=PWD"
> >
> > But I got the following exception:
> >
> > [Broker] BRK-1016 : Fatal error : Cannot create provided preference
> > store on non PreferenceStoreProvider : See log file for more
> > information [Broker] Exception during startup:
> > org.apache.qpid.server.util.ServerScopedRuntimeException: Broker
> > failed reach ACTIVE state (state is ERRORED)
> > at
> > org.apache.qpid.server.model.AbstractSystemConfig$3.onSuccess(Abstract
> > SystemConfig.java:318)
> >
> > I debugged a bit and it uses the ProvidedPreferenceStoreFactoryService.
> > But it is called with JDBCSystemConfigImpl as parent which does not
> > implement PreferenceStoreProvider, thus the crash.
> >
> > First, what is exactly the preference store and do I really need it?
>
>
> It is where per-user preferences for the web console are stored.  The
> default is to use JSON - so at some point the configuration must have been
> edited to use "provided" instead.
>
> If not how can I configure my broker to use the NOOP one?
> >
>
> The type of preference store to use is defined in the attribute
> "preferenceStoreAttributes" in the system config.  The default value is the
> JSON object "{\"type\": \"JSON\", \"attributes\":{\"path\":
> \"${json:qpid.work_dir}${json:file.separator}preferences.json\"}}".  If
> you wanted to change that to the NoOp provider you could use "{\"type\":
> \"Noop\", \"attributes\":{}}" I would think.
>
>
>
> > Second, why isn't it working with a JDBC config store, did I miss
> > something in the configuration?
> >
>
> It's just never been implemented - I'm not sure why, I guess because there
> wasn't really seen to be a demand.
>
>
> >
> > Thanks,
> > Olivier
> >
> >
> -- Rob
>
>
> > *** 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.
>

Re: [Broker-J] JDBC config store

[Rob Godfrey]

On Thu, 22 Nov 2018 at 15:11, VERMEULEN Olivier 
wrote:

> Hello,
>
> I'm using version 7.0.3 of the Broker-J.
> I tried to configure it to use a JDBC (here Sybase) config store.
>
> qpid-server.bat -st JDBC -prop
> "systemConfig.connectionUrl=jdbc:sybase:Tds:dell719srv:4100/DB" -prop
> "systemConfig.username=USER" -prop
> "systemConfig.password=PWD"
>
> But I got the following exception:
>
> [Broker] BRK-1016 : Fatal error : Cannot create provided preference store
> on non PreferenceStoreProvider : See log file for more information
> [Broker] Exception during startup:
> org.apache.qpid.server.util.ServerScopedRuntimeException: Broker failed
> reach ACTIVE state (state is ERRORED)
> at
> org.apache.qpid.server.model.AbstractSystemConfig$3.onSuccess(AbstractSystemConfig.java:318)
>
> I debugged a bit and it uses the ProvidedPreferenceStoreFactoryService.
> But it is called with JDBCSystemConfigImpl as parent which does not
> implement PreferenceStoreProvider, thus the crash.
>
> First, what is exactly the preference store and do I really need it?


It is where per-user preferences for the web console are stored.  The
default is to use JSON - so at some point the configuration must have been
edited to use "provided" instead.

If not how can I configure my broker to use the NOOP one?
>

The type of preference store to use is defined in the attribute
"preferenceStoreAttributes" in the system config.  The default value is the
JSON object "{\"type\": \"JSON\", \"attributes\":{\"path\":
\"${json:qpid.work_dir}${json:file.separator}preferences.json\"}}".  If you
wanted to change that to the NoOp provider you could use "{\"type\":
\"Noop\", \"attributes\":{}}" I would think.



> Second, why isn't it working with a JDBC config store, did I miss
> something in the configuration?
>

It's just never been implemented - I'm not sure why, I guess because there
wasn't really seen to be a demand.


>
> Thanks,
> Olivier
>
>
-- Rob


> *** 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.
>

Re: Changing system time causes J-Broker to drop connections

[Rob Godfrey]

The Qpid Broker-J uses offsets from System.currentTimeMillis (defined by
Java as "the difference, measured in milliseconds, between the current time
and midnight, January 1, 1970 UTC") and so should not be affected by
changed to DST or whatever.  Suspending/resuming inside a VM would be a
different case as the connection will actually have been idle while the VM
is suspended.

When you see these disconnections occurring when changing timezone / DST
have you turned on protocol tracing...can we see clients which have been
sending traffic being disconnected?

-- Rob

On Thu, 15 Nov 2018 at 11:44, Sami Siitonen 
wrote:

> Hello,
>
> I've setup J-Broker version 6.1.4 on Windows 10 platform using OpenJDK
> version 9.0.0.1-ojdkbuildea and using RabbitMQ-client version 4.1.3 from
> .Net. The problem is very similar to this bug description in the
> C++-broker: https://bugzilla.redhat.com/show_bug.cgi?id=1080165 The
> broker drops all connections every time when system time is changed (for
> example daylight saving time changes, running broker in virtual machine and
> suspending/resuming it etc). It can be repeated by changing system time
> more than timeout limit. It seems like walltime is used instead of
> monotonic time where calculating timeouts are performed.
>
> I' ve managed to workaround this by disabling heartbeating in the client
> side but obviously this is not a proper solution. I couldn't find any bug
> report about this problem at J-Broker so I'm asking that if this is some
> configuration problem or problem with JDK or is this bug in J-Broker. I
> also tried to upgrade the broker to version 7.0.6 and RabbitMQ to 5.1.0
> with no effect.
>
> Cheers,
> Sami
>

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

Hi Olivier,

I'm not terribly surprised... I've not tested extensively with JDBC, but my
experience with BDB and batch sizes was similar.  If you are happy with the
original patch I'll apply that on trunk from QPID-8242.

-- Rob

On Mon, 29 Oct 2018 at 15:41, VERMEULEN Olivier 
wrote:

> Hello Rob,
>
> I modified your patch to set a minimum batch size of 10 but didn't see any
> improvement in the overall throughput...
>
> Olivier
>
> -Original Message-
> From: Rob Godfrey 
> Sent: mardi 2 octobre 2018 18:08
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] JDBC message store performance
>
> On Tue, 2 Oct 2018 at 17:47, VERMEULEN Olivier <
> olivier.vermeu...@murex.com>
> wrote:
>
> > Hello Rob,
> >
> > We tested your fix on an Oracle database and it works fine, we even
> > noticed a 7% improvement of the overall throughput!
> >
>
> Great!
>
>
> > But the average size of the batches is quite small: between 3 or 4.
> > Do you think it would possible (and a good idea) to define a minimum
> > batch size and/or a batch period?
> >
> >
> Sure - the only potential "issue" is having more orphan message content
> rows in the database if you have an abrupt shutdown of the broker; on
> restart these should be cleaned up anyway by the recovery process.  I'm not
> sure if you would see much performance benefit (my guess is that a lot of
> the benefit you will see if from taking the message deletion off the
> critical path on message delivery) but we could experiment with a tiny
> change to the patch to make a minimum batch size of 10 or whatever and see
> if you get a further speedup.
>
> -- Rob
>
>
> > Olivier
> >
> > -Original Message-
> > From: Rob Godfrey 
> > Sent: mardi 25 septembre 2018 13:20
> > To: users@qpid.apache.org
> > Subject: Re: [Broker-J] JDBC message store performance
> >
> > And now with a fix to allow the system tests to pass consistently
> >
> > https://issues.apache.org/jira/secure/attachment/12941197/QPID-8242.pa
> > tch
> >
> > -- Rob
> >
> > On Tue, 25 Sep 2018 at 12:24, Rob Godfrey 
> wrote:
> >
> > > D'oh - no idea what happened there.
> > >
> > > Re-attached with an actual diff this time (I hope :) )
> > >
> > > https://issues.apache.org/jira/secure/attachment/12941192/QPID-8242.
> > > pa
> > > tch
> > >
> > > -- Rob
> > >
> > > On Wed, 19 Sep 2018 at 01:23, Rob Godfrey 
> > wrote:
> > >
> > >> As an alternative approach, how about the (totally untested) patch
> > >> I've attached to QPID-8242 [1]
> > >>
> > >> Rather than trying to consolidate the commits to delete the queue
> > >> entry and the message content it instead attempts to delete the
> > >> message content asynchronously and batch up all message contents
> > >> awaiting deletion.  From a performance point of view, on the broker
> > >> it takes the message content deletion off the connection thread,
> > >> and if the database is being the bottleneck it should start
> > >> batching up the
> > deletions of content.
> > >>
> > >> -- Rob
> > >>
> > >> [1]
> > >> https://issues.apache.org/jira/secure/attachment/12940318/QPID-8242
> > >> .p
> > >> atch
> > >>
> > >> On Mon, 17 Sep 2018 at 15:22, Rob Godfrey 
> > >> wrote:
> > >>
> > >>> The reference counting is done in AbstractServerMessageImpl.java.
> > >>> In general instances of ServerMessage should not be passed around,
> > >>> rather a MessageReference (obtained by calling newReference(..) on
> > >>> the message object.  Then if the message is no longer required in
> > >>> that context,
> > >>> release() can be called on the reference.  Within the context of a
> > >>> queue this is normally encapsulated by the notion of the
> > >>> QueueEntry (which holds the relevant MessageReference).  When
> > >>> delete() is called on the QueueEntry (delete being defined in the
> > >>> MessageInstance interface), this releases the reference, which
> > >>> decrements the reference count, and if the count has gone to zero
> > >>> the
> > message calls the store to delete itself.
> > >>>
> > >>> I think trying to change this logic would be a bit of a nightmare
> > >>> (understatement).  I think a better alt

Re: [Broker-J] Limit connections per user

[Rob Godfrey]

Hi Tomas,

On Mon, 15 Oct 2018 at 09:59, Vavricka  wrote:

> Hi,
>
> is it possible to limit maximum number of AMQP connections per user basis?
>
> I can set maximum number of connections for AMQP port, but then one user
> can
> create maximum number of connections and this user will block other users
> connections.
>
>
No, there are currently no mechanisms to assign "resource limits" such as
this to users (or groups, or IP addresses for that matter).  It would be a
nice enhancement, but probably not trivial to implement.

-- Rob


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

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

On Tue, 2 Oct 2018 at 17:47, VERMEULEN Olivier 
wrote:

> Hello Rob,
>
> We tested your fix on an Oracle database and it works fine, we even
> noticed a 7% improvement of the overall throughput!
>

Great!


> But the average size of the batches is quite small: between 3 or 4.
> Do you think it would possible (and a good idea) to define a minimum batch
> size and/or a batch period?
>
>
Sure - the only potential "issue" is having more orphan message content
rows in the database if you have an abrupt shutdown of the broker; on
restart these should be cleaned up anyway by the recovery process.  I'm not
sure if you would see much performance benefit (my guess is that a lot of
the benefit you will see if from taking the message deletion off the
critical path on message delivery) but we could experiment with a tiny
change to the patch to make a minimum batch size of 10 or whatever and see
if you get a further speedup.

-- Rob


> Olivier
>
> -Original Message-
> From: Rob Godfrey 
> Sent: mardi 25 septembre 2018 13:20
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] JDBC message store performance
>
> And now with a fix to allow the system tests to pass consistently
>
> https://issues.apache.org/jira/secure/attachment/12941197/QPID-8242.patch
>
> -- Rob
>
> On Tue, 25 Sep 2018 at 12:24, Rob Godfrey  wrote:
>
> > D'oh - no idea what happened there.
> >
> > Re-attached with an actual diff this time (I hope :) )
> >
> > https://issues.apache.org/jira/secure/attachment/12941192/QPID-8242.pa
> > tch
> >
> > -- Rob
> >
> > On Wed, 19 Sep 2018 at 01:23, Rob Godfrey 
> wrote:
> >
> >> As an alternative approach, how about the (totally untested) patch
> >> I've attached to QPID-8242 [1]
> >>
> >> Rather than trying to consolidate the commits to delete the queue
> >> entry and the message content it instead attempts to delete the
> >> message content asynchronously and batch up all message contents
> >> awaiting deletion.  From a performance point of view, on the broker
> >> it takes the message content deletion off the connection thread, and
> >> if the database is being the bottleneck it should start batching up the
> deletions of content.
> >>
> >> -- Rob
> >>
> >> [1]
> >> https://issues.apache.org/jira/secure/attachment/12940318/QPID-8242.p
> >> atch
> >>
> >> On Mon, 17 Sep 2018 at 15:22, Rob Godfrey 
> >> wrote:
> >>
> >>> The reference counting is done in AbstractServerMessageImpl.java.
> >>> In general instances of ServerMessage should not be passed around,
> >>> rather a MessageReference (obtained by calling newReference(..) on
> >>> the message object.  Then if the message is no longer required in
> >>> that context,
> >>> release() can be called on the reference.  Within the context of a
> >>> queue this is normally encapsulated by the notion of the QueueEntry
> >>> (which holds the relevant MessageReference).  When delete() is
> >>> called on the QueueEntry (delete being defined in the
> >>> MessageInstance interface), this releases the reference, which
> >>> decrements the reference count, and if the count has gone to zero the
> message calls the store to delete itself.
> >>>
> >>> I think trying to change this logic would be a bit of a nightmare
> >>> (understatement).  I think a better alternative in terms of reducing
> >>> the number of commits in the JDBC store might instead be for the
> >>> remove() method on StoredJDBCMessage to (rather than immediately
> >>> commit the message
> >>> delete) schedule the message removal to be picked up by the next
> >>> commit that the store is asked to perform.  This would make the
> >>> behaviour more like the BDB store (where we schedule the commit but
> >>> don't actually force the sync to disk on message deletion).
> >>>
> >>> -- Rob
> >>>
> >>> On Mon, 17 Sep 2018 at 14:55, VERMEULEN Olivier <
> >>> olivier.vermeu...@murex.com> wrote:
> >>>
> >>>> Ok then I missed something.
> >>>> Whan/Where is the reference-counting you were talking about in your
> >>>> first mail happening?
> >>>>
> >>>> Olivier
> >>>>
> >>>> -Original Message-
> >>>> From: Rob Godfrey 
> >>>> Sent: lundi 17 septembre 2018 14:05
> >>>> To: users@qpid.apache.org
> >

Re: Building Qpid broker 7.0.6 Java version with OpenJDK 1.8.0_162_x64 fails in BDB Link Store Plug-in tests

[Rob Godfrey]

Then it looks like the issue you are seeing is that that Alex identified
(i.e. it is a BDB issue and thus outside of our control in Qpid), obviously
if you are not using the BDB store then you can simply exclude it from your
build / dependencies.

-- Rob

On Tue, 25 Sep 2018 at 20:26, Brian O'Shea  wrote:

> Thank you for your responses, Rob and Alex.
> We are using the Zulu OpenJDK from Azul:
> https://www.azul.com/products/zulu-enterprise/
> This is the JVM that I am using:
> $ ./java -showversionopenjdk version "1.8.0_172"OpenJDK Runtime Environment
> (Zulu 8.30.0.2-linux64) (build 1.8.0_172-b01)OpenJDK 64-Bit Server VM (Zulu
> 8.30.0.2-linux64) (build 25.172-b01, mixed mode)
>
>
>
>
> --
> Sent from:
> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

And now with a fix to allow the system tests to pass consistently

https://issues.apache.org/jira/secure/attachment/12941197/QPID-8242.patch

-- Rob

On Tue, 25 Sep 2018 at 12:24, Rob Godfrey  wrote:

> D'oh - no idea what happened there.
>
> Re-attached with an actual diff this time (I hope :) )
>
> https://issues.apache.org/jira/secure/attachment/12941192/QPID-8242.patch
>
> -- Rob
>
> On Wed, 19 Sep 2018 at 01:23, Rob Godfrey  wrote:
>
>> As an alternative approach, how about the (totally untested) patch I've
>> attached to QPID-8242 [1]
>>
>> Rather than trying to consolidate the commits to delete the queue entry
>> and the message content it instead attempts to delete the message content
>> asynchronously and batch up all message contents awaiting deletion.  From a
>> performance point of view, on the broker it takes the message content
>> deletion off the connection thread, and if the database is being the
>> bottleneck it should start batching up the deletions of content.
>>
>> -- Rob
>>
>> [1]
>> https://issues.apache.org/jira/secure/attachment/12940318/QPID-8242.patch
>>
>> On Mon, 17 Sep 2018 at 15:22, Rob Godfrey 
>> wrote:
>>
>>> The reference counting is done in AbstractServerMessageImpl.java.  In
>>> general instances of ServerMessage should not be passed around, rather a
>>> MessageReference (obtained by calling newReference(..) on the message
>>> object.  Then if the message is no longer required in that context,
>>> release() can be called on the reference.  Within the context of a queue
>>> this is normally encapsulated by the notion of the QueueEntry (which holds
>>> the relevant MessageReference).  When delete() is called on the QueueEntry
>>> (delete being defined in the MessageInstance interface), this releases the
>>> reference, which decrements the reference count, and if the count has gone
>>> to zero the message calls the store to delete itself.
>>>
>>> I think trying to change this logic would be a bit of a nightmare
>>> (understatement).  I think a better alternative in terms of reducing the
>>> number of commits in the JDBC store might instead be for the remove()
>>> method on StoredJDBCMessage to (rather than immediately commit the message
>>> delete) schedule the message removal to be picked up by the next commit
>>> that the store is asked to perform.  This would make the behaviour more
>>> like the BDB store (where we schedule the commit but don't actually force
>>> the sync to disk on message deletion).
>>>
>>> -- Rob
>>>
>>> On Mon, 17 Sep 2018 at 14:55, VERMEULEN Olivier <
>>> olivier.vermeu...@murex.com> wrote:
>>>
>>>> Ok then I missed something.
>>>> Whan/Where is the reference-counting you were talking about in your
>>>> first mail happening?
>>>>
>>>> Olivier
>>>>
>>>> -Original Message-
>>>> From: Rob Godfrey 
>>>> Sent: lundi 17 septembre 2018 14:05
>>>> To: users@qpid.apache.org
>>>> Subject: Re: [Broker-J] JDBC message store performance
>>>>
>>>> Hi Olivier,
>>>>
>>>> the approach you are attempting will not work for the reasons I
>>>> described previously.  If the message has (for instance) been placed in two
>>>> durable subscription queues (because there are two durable subscriptions)
>>>> then as soon as the message is consumed from the first queue it would be
>>>> removed from the store, leading to problems when the second consumer tries
>>>> to read the message.
>>>>
>>>> -- Rob
>>>>
>>>> On Mon, 17 Sep 2018 at 11:39, VERMEULEN Olivier <
>>>> olivier.vermeu...@murex.com>
>>>> wrote:
>>>>
>>>> > Hello Rob,
>>>> >
>>>> > Thanks for the answer.
>>>> > I started looking at the code to see if there is something I can do
>>>> > about these 2 commits.
>>>> > But before going any further I'd like your input on the below, to see
>>>> > if what I'm trying to do could work or if I'm missing something
>>>> (which
>>>> > I'm surely are)
>>>> >
>>>> >
>>>> https://github.com/apache/qpid-broker-j/compare/master...overmeulen:fe
>>>> > ature/jdbc-message-store-commits
>>>> >
>>>> > Regards,
>>>> > Olivier
>>>> >
>>>> &g

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

D'oh - no idea what happened there.

Re-attached with an actual diff this time (I hope :) )

https://issues.apache.org/jira/secure/attachment/12941192/QPID-8242.patch

-- Rob

On Wed, 19 Sep 2018 at 01:23, Rob Godfrey  wrote:

> As an alternative approach, how about the (totally untested) patch I've
> attached to QPID-8242 [1]
>
> Rather than trying to consolidate the commits to delete the queue entry
> and the message content it instead attempts to delete the message content
> asynchronously and batch up all message contents awaiting deletion.  From a
> performance point of view, on the broker it takes the message content
> deletion off the connection thread, and if the database is being the
> bottleneck it should start batching up the deletions of content.
>
> -- Rob
>
> [1]
> https://issues.apache.org/jira/secure/attachment/12940318/QPID-8242.patch
>
> On Mon, 17 Sep 2018 at 15:22, Rob Godfrey  wrote:
>
>> The reference counting is done in AbstractServerMessageImpl.java.  In
>> general instances of ServerMessage should not be passed around, rather a
>> MessageReference (obtained by calling newReference(..) on the message
>> object.  Then if the message is no longer required in that context,
>> release() can be called on the reference.  Within the context of a queue
>> this is normally encapsulated by the notion of the QueueEntry (which holds
>> the relevant MessageReference).  When delete() is called on the QueueEntry
>> (delete being defined in the MessageInstance interface), this releases the
>> reference, which decrements the reference count, and if the count has gone
>> to zero the message calls the store to delete itself.
>>
>> I think trying to change this logic would be a bit of a nightmare
>> (understatement).  I think a better alternative in terms of reducing the
>> number of commits in the JDBC store might instead be for the remove()
>> method on StoredJDBCMessage to (rather than immediately commit the message
>> delete) schedule the message removal to be picked up by the next commit
>> that the store is asked to perform.  This would make the behaviour more
>> like the BDB store (where we schedule the commit but don't actually force
>> the sync to disk on message deletion).
>>
>> -- Rob
>>
>> On Mon, 17 Sep 2018 at 14:55, VERMEULEN Olivier <
>> olivier.vermeu...@murex.com> wrote:
>>
>>> Ok then I missed something.
>>> Whan/Where is the reference-counting you were talking about in your
>>> first mail happening?
>>>
>>> Olivier
>>>
>>> -Original Message-
>>> From: Rob Godfrey 
>>> Sent: lundi 17 septembre 2018 14:05
>>> To: users@qpid.apache.org
>>> Subject: Re: [Broker-J] JDBC message store performance
>>>
>>> Hi Olivier,
>>>
>>> the approach you are attempting will not work for the reasons I
>>> described previously.  If the message has (for instance) been placed in two
>>> durable subscription queues (because there are two durable subscriptions)
>>> then as soon as the message is consumed from the first queue it would be
>>> removed from the store, leading to problems when the second consumer tries
>>> to read the message.
>>>
>>> -- Rob
>>>
>>> On Mon, 17 Sep 2018 at 11:39, VERMEULEN Olivier <
>>> olivier.vermeu...@murex.com>
>>> wrote:
>>>
>>> > Hello Rob,
>>> >
>>> > Thanks for the answer.
>>> > I started looking at the code to see if there is something I can do
>>> > about these 2 commits.
>>> > But before going any further I'd like your input on the below, to see
>>> > if what I'm trying to do could work or if I'm missing something (which
>>> > I'm surely are)
>>> >
>>> > https://github.com/apache/qpid-broker-j/compare/master...overmeulen:fe
>>> > ature/jdbc-message-store-commits
>>> >
>>> > Regards,
>>> > Olivier
>>> >
>>> > -Original Message-
>>> > From: Rob Godfrey 
>>> > Sent: vendredi 14 septembre 2018 16:06
>>> > To: users@qpid.apache.org
>>> > Cc: AYOUBI Ali 
>>> > Subject: Re: [Broker-J] JDBC message store performance
>>> >
>>> > On Fri, 14 Sep 2018 at 15:30, VERMEULEN Olivier <
>>> > olivier.vermeu...@murex.com>
>>> > wrote:
>>> >
>>> > > Hello,
>>> > >
>>> > > We ran a performance test with a bunch of brokers and an Oracle
>>> > 

Re: Building Qpid broker 7.0.6 Java version with OpenJDK 1.8.0_162_x64 fails in BDB Link Store Plug-in tests

[Rob Godfrey]

On Tue, 25 Sep 2018 at 01:23, Brian O'Shea  wrote:

> Hello Qpid developers,
>
> I am trying to build the Qpid broker version 7.0.6 Java version, and it is
> failing the BDB Link Store Plug-in tests.  I am building on an Intel 64-bit
> system running Ubuntu Linux 16.04 with OpenJDK 1.8.0_162_x64.  I have
> searched for the errors that I am seeing but can't find anything.  We are
> transitioning to OpenJDK and so I would like to be able to use it to build
> and run the Qpid broker.  Can you provide any advice on how to build this
> successfully?
>
>
The errors you are seeing seem to reference classes from com.azul.zing.* -
when you say you are using "OpenJDK" are you intending to use an
implementation from Azul?  To my knowledge Broker-J builds fine using the
OpenJDK from openjdk.java.net.  I've never personally tried building with
Azul's products.

-- Rob


> Thank you and regards,
> Brian O'Shea
>
> When I build with the Oracle JDK of the same version it builds successfully
> and all tests pass.  Here is the error that I am getting:
>
> Running
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTestTests
> run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.625 sec <<<
> FAILURE! - in
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTesttestOpenAndLoad(org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest)
>
> Time elapsed: 0.331 sec  <<< ERROR!java.lang.IllegalStateException: Could
> not access Zing management bean. Make sure -XX:+UseZingMXBeans was
> specified.  at
>
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)Caused
> by: java.lang.ClassNotFoundException:
> com.azul.zing.management.ManagementFactory  at
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)testSaveLink(org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest)
>
> Time elapsed: 0.006 sec  <<< ERROR!java.lang.IllegalStateException: Could
> not access Zing management bean. Make sure -XX:+UseZingMXBeans was
> specified.  at
>
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)Caused
> by: java.lang.ClassNotFoundException:
> com.azul.zing.management.ManagementFactory  at
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)testClose(org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest)
>
> Time elapsed: 0.004 sec  <<< ERROR!java.lang.IllegalStateException: Could
> not access Zing management bean. Make sure -XX:+UseZingMXBeans was
> specified.  at
>
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)Caused
> by: java.lang.ClassNotFoundException:
> com.azul.zing.management.ManagementFactory  at
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)testDeleteLink(org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest)
>
> Time elapsed: 0.01 sec  <<< ERROR!java.lang.IllegalStateException: Could
> not
> access Zing management bean. Make sure -XX:+UseZingMXBeans was specified.
>  at
>
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)Caused
> by: java.lang.ClassNotFoundException:
> com.azul.zing.management.ManagementFactory  at
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)testDelete(org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest)
>
> Time elapsed: 0.007 sec  <<< ERROR!java.lang.IllegalStateException: Could
> not access Zing management bean. Make sure -XX:+UseZingMXBeans was
> specified.  at
>
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)Caused
> by: java.lang.ClassNotFoundException:
> com.azul.zing.management.ManagementFactory  at
>
> org.apache.qpid.server.protocol.v1_0.store.bdb.BDBLinkStoreTest.createLinkStore(BDBLinkStoreTest.java:68)Results
> :Tests in error:
>
> BDBLinkStoreTest>QpidTestCase.run:165->LinkStoreTestCase.setUp:55->createLinkStore:68
> » IllegalState
>
> BDBLinkStoreTest>QpidTestCase.run:165->LinkStoreTestCase.setUp:55->createLinkStore:68
> » IllegalState
>
> BDBLinkStoreTest>QpidTestCase.run:165->LinkStoreTestCase.setUp:55->createLinkStore:68
> » IllegalState
>
> BDBLinkStoreTest>QpidTestCase.run:165->LinkStoreTestCase.setUp:55->createLinkStore:68
> » IllegalState
>
> BDBLinkStoreTest>QpidTestCase.run:165->LinkStoreTestCase.setUp:55->createLinkStore:68
> » IllegalStateTests run: 5, Failures: 0, Errors: 5, Skipped: 0[INFO]
>
> [INFO]
> Reactor Summary:[INFO] [INFO] Apache Qpid Broker-J Parent
>  SUCCESS [  1.945 s][INFO] Apache Qpid Broker-J
> Code
> Generation ... SUCCESS [  1.593 s][INFO] 

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

I'm on vacation at the moment, but if I get a chance I'll at least try to
test with Derby.

-- Rob

On Wed, 19 Sep 2018 at 09:14, VERMEULEN Olivier 
wrote:

> Thanks a lot Rob, I'll try to test that next week.
>
> Olivier
>
> -Original Message-----
> From: Rob Godfrey 
> Sent: mercredi 19 septembre 2018 01:23
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] JDBC message store performance
>
> As an alternative approach, how about the (totally untested) patch I've
> attached to QPID-8242 [1]
>
> Rather than trying to consolidate the commits to delete the queue entry
> and the message content it instead attempts to delete the message content
> asynchronously and batch up all message contents awaiting deletion.  From a
> performance point of view, on the broker it takes the message content
> deletion off the connection thread, and if the database is being the
> bottleneck it should start batching up the deletions of content.
>
> -- Rob
>
> [1]
> https://issues.apache.org/jira/secure/attachment/12940318/QPID-8242.patch
>
> On Mon, 17 Sep 2018 at 15:22, Rob Godfrey  wrote:
>
> > The reference counting is done in AbstractServerMessageImpl.java.  In
> > general instances of ServerMessage should not be passed around, rather
> > a MessageReference (obtained by calling newReference(..) on the
> > message object.  Then if the message is no longer required in that
> > context,
> > release() can be called on the reference.  Within the context of a
> > queue this is normally encapsulated by the notion of the QueueEntry
> > (which holds the relevant MessageReference).  When delete() is called
> > on the QueueEntry (delete being defined in the MessageInstance
> > interface), this releases the reference, which decrements the
> > reference count, and if the count has gone to zero the message calls the
> store to delete itself.
> >
> > I think trying to change this logic would be a bit of a nightmare
> > (understatement).  I think a better alternative in terms of reducing
> > the number of commits in the JDBC store might instead be for the
> > remove() method on StoredJDBCMessage to (rather than immediately
> > commit the message
> > delete) schedule the message removal to be picked up by the next
> > commit that the store is asked to perform.  This would make the
> > behaviour more like the BDB store (where we schedule the commit but
> > don't actually force the sync to disk on message deletion).
> >
> > -- Rob
> >
> > On Mon, 17 Sep 2018 at 14:55, VERMEULEN Olivier <
> > olivier.vermeu...@murex.com> wrote:
> >
> >> Ok then I missed something.
> >> Whan/Where is the reference-counting you were talking about in your
> >> first mail happening?
> >>
> >> Olivier
> >>
> >> -Original Message-
> >> From: Rob Godfrey 
> >> Sent: lundi 17 septembre 2018 14:05
> >> To: users@qpid.apache.org
> >> Subject: Re: [Broker-J] JDBC message store performance
> >>
> >> Hi Olivier,
> >>
> >> the approach you are attempting will not work for the reasons I
> >> described previously.  If the message has (for instance) been placed
> >> in two durable subscription queues (because there are two durable
> >> subscriptions) then as soon as the message is consumed from the first
> >> queue it would be removed from the store, leading to problems when
> >> the second consumer tries to read the message.
> >>
> >> -- Rob
> >>
> >> On Mon, 17 Sep 2018 at 11:39, VERMEULEN Olivier <
> >> olivier.vermeu...@murex.com>
> >> wrote:
> >>
> >> > Hello Rob,
> >> >
> >> > Thanks for the answer.
> >> > I started looking at the code to see if there is something I can do
> >> > about these 2 commits.
> >> > But before going any further I'd like your input on the below, to
> >> > see if what I'm trying to do could work or if I'm missing something
> >> > (which I'm surely are)
> >> >
> >> > https://github.com/apache/qpid-broker-j/compare/master...overmeulen
> >> > :fe
> >> > ature/jdbc-message-store-commits
> >> >
> >> > Regards,
> >> > Olivier
> >> >
> >> > -Original Message-
> >> > From: Rob Godfrey 
> >> > Sent: vendredi 14 septembre 2018 16:06
> >> > To: users@qpid.apache.org
> >> > Cc: AYOUBI Ali 
> >> > Subject: Re: [Broker-J] JDBC message store p

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

As an alternative approach, how about the (totally untested) patch I've
attached to QPID-8242 [1]

Rather than trying to consolidate the commits to delete the queue entry and
the message content it instead attempts to delete the message content
asynchronously and batch up all message contents awaiting deletion.  From a
performance point of view, on the broker it takes the message content
deletion off the connection thread, and if the database is being the
bottleneck it should start batching up the deletions of content.

-- Rob

[1]
https://issues.apache.org/jira/secure/attachment/12940318/QPID-8242.patch

On Mon, 17 Sep 2018 at 15:22, Rob Godfrey  wrote:

> The reference counting is done in AbstractServerMessageImpl.java.  In
> general instances of ServerMessage should not be passed around, rather a
> MessageReference (obtained by calling newReference(..) on the message
> object.  Then if the message is no longer required in that context,
> release() can be called on the reference.  Within the context of a queue
> this is normally encapsulated by the notion of the QueueEntry (which holds
> the relevant MessageReference).  When delete() is called on the QueueEntry
> (delete being defined in the MessageInstance interface), this releases the
> reference, which decrements the reference count, and if the count has gone
> to zero the message calls the store to delete itself.
>
> I think trying to change this logic would be a bit of a nightmare
> (understatement).  I think a better alternative in terms of reducing the
> number of commits in the JDBC store might instead be for the remove()
> method on StoredJDBCMessage to (rather than immediately commit the message
> delete) schedule the message removal to be picked up by the next commit
> that the store is asked to perform.  This would make the behaviour more
> like the BDB store (where we schedule the commit but don't actually force
> the sync to disk on message deletion).
>
> -- Rob
>
> On Mon, 17 Sep 2018 at 14:55, VERMEULEN Olivier <
> olivier.vermeu...@murex.com> wrote:
>
>> Ok then I missed something.
>> Whan/Where is the reference-counting you were talking about in your first
>> mail happening?
>>
>> Olivier
>>
>> -Original Message-
>> From: Rob Godfrey 
>> Sent: lundi 17 septembre 2018 14:05
>> To: users@qpid.apache.org
>> Subject: Re: [Broker-J] JDBC message store performance
>>
>> Hi Olivier,
>>
>> the approach you are attempting will not work for the reasons I described
>> previously.  If the message has (for instance) been placed in two durable
>> subscription queues (because there are two durable subscriptions) then as
>> soon as the message is consumed from the first queue it would be removed
>> from the store, leading to problems when the second consumer tries to read
>> the message.
>>
>> -- Rob
>>
>> On Mon, 17 Sep 2018 at 11:39, VERMEULEN Olivier <
>> olivier.vermeu...@murex.com>
>> wrote:
>>
>> > Hello Rob,
>> >
>> > Thanks for the answer.
>> > I started looking at the code to see if there is something I can do
>> > about these 2 commits.
>> > But before going any further I'd like your input on the below, to see
>> > if what I'm trying to do could work or if I'm missing something (which
>> > I'm surely are)
>> >
>> > https://github.com/apache/qpid-broker-j/compare/master...overmeulen:fe
>> > ature/jdbc-message-store-commits
>> >
>> > Regards,
>> > Olivier
>> >
>> > -Original Message-
>> > From: Rob Godfrey 
>> > Sent: vendredi 14 septembre 2018 16:06
>> > To: users@qpid.apache.org
>> > Cc: AYOUBI Ali 
>> > Subject: Re: [Broker-J] JDBC message store performance
>> >
>> > On Fri, 14 Sep 2018 at 15:30, VERMEULEN Olivier <
>> > olivier.vermeu...@murex.com>
>> > wrote:
>> >
>> > > Hello,
>> > >
>> > > We ran a performance test with a bunch of brokers and an Oracle
>> > > database to store the messages.
>> > > We noticed that the database was a bit overloaded with commits.
>> > > Looking at the logs we saw that sending a message was triggering 1
>> > > commit for 3 operations (QPID_QUEUE_ENTRIES, QPID_MESSAGE_METADATA,
>> > > QPID_MESSAGE_CONTENT) which is what we were expecting but receiving
>> > > a message was triggering 2 commits (1 for QPID_QUEUE_ENTRIES and 1
>> > > for QPID_MESSAGE_METADATA and QPID_MESSAGE_CONTENT).
>> > > I debugged a bit the code and saw that in
>> > > AbstractVirtualHost.execut

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

The reference counting is done in AbstractServerMessageImpl.java.  In
general instances of ServerMessage should not be passed around, rather a
MessageReference (obtained by calling newReference(..) on the message
object.  Then if the message is no longer required in that context,
release() can be called on the reference.  Within the context of a queue
this is normally encapsulated by the notion of the QueueEntry (which holds
the relevant MessageReference).  When delete() is called on the QueueEntry
(delete being defined in the MessageInstance interface), this releases the
reference, which decrements the reference count, and if the count has gone
to zero the message calls the store to delete itself.

I think trying to change this logic would be a bit of a nightmare
(understatement).  I think a better alternative in terms of reducing the
number of commits in the JDBC store might instead be for the remove()
method on StoredJDBCMessage to (rather than immediately commit the message
delete) schedule the message removal to be picked up by the next commit
that the store is asked to perform.  This would make the behaviour more
like the BDB store (where we schedule the commit but don't actually force
the sync to disk on message deletion).

-- Rob

On Mon, 17 Sep 2018 at 14:55, VERMEULEN Olivier 
wrote:

> Ok then I missed something.
> Whan/Where is the reference-counting you were talking about in your first
> mail happening?
>
> Olivier
>
> -Original Message-
> From: Rob Godfrey 
> Sent: lundi 17 septembre 2018 14:05
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] JDBC message store performance
>
> Hi Olivier,
>
> the approach you are attempting will not work for the reasons I described
> previously.  If the message has (for instance) been placed in two durable
> subscription queues (because there are two durable subscriptions) then as
> soon as the message is consumed from the first queue it would be removed
> from the store, leading to problems when the second consumer tries to read
> the message.
>
> -- Rob
>
> On Mon, 17 Sep 2018 at 11:39, VERMEULEN Olivier <
> olivier.vermeu...@murex.com>
> wrote:
>
> > Hello Rob,
> >
> > Thanks for the answer.
> > I started looking at the code to see if there is something I can do
> > about these 2 commits.
> > But before going any further I'd like your input on the below, to see
> > if what I'm trying to do could work or if I'm missing something (which
> > I'm surely are)
> >
> > https://github.com/apache/qpid-broker-j/compare/master...overmeulen:fe
> > ature/jdbc-message-store-commits
> >
> > Regards,
> > Olivier
> >
> > -Original Message-
> > From: Rob Godfrey 
> > Sent: vendredi 14 septembre 2018 16:06
> > To: users@qpid.apache.org
> > Cc: AYOUBI Ali 
> > Subject: Re: [Broker-J] JDBC message store performance
> >
> > On Fri, 14 Sep 2018 at 15:30, VERMEULEN Olivier <
> > olivier.vermeu...@murex.com>
> > wrote:
> >
> > > Hello,
> > >
> > > We ran a performance test with a bunch of brokers and an Oracle
> > > database to store the messages.
> > > We noticed that the database was a bit overloaded with commits.
> > > Looking at the logs we saw that sending a message was triggering 1
> > > commit for 3 operations (QPID_QUEUE_ENTRIES, QPID_MESSAGE_METADATA,
> > > QPID_MESSAGE_CONTENT) which is what we were expecting but receiving
> > > a message was triggering 2 commits (1 for QPID_QUEUE_ENTRIES and 1
> > > for QPID_MESSAGE_METADATA and QPID_MESSAGE_CONTENT).
> > > I debugged a bit the code and saw that in
> > > AbstractVirtualHost.executeTransaction the delete on
> > > QPID_MESSAGE_METADATA and QPID_MESSAGE_CONTENT was defined as a
> > > "post commit" operation, explaining why we have 2 commits.
> > > Is it something expected? Do you think we could reduce this to 1
> > > commit when receiving a message?
> > >
> >
> > It's not unexpected - basically the issue is that the broker needs to
> > cope with the possibility that the same message is being stored on
> > multiple queues.  The first commit is deleting the referencing of the
> > message from the given queue.  The second commit is occuring after the
> > message has been definitively removed from the queue, and the store
> > has determined that there are no more references, so it is ok to
> > remove the message.  This is driven by reference-counting of the
> > message, and has historically been a place of many potential race
> > conditions.  I'm sure it is possible to optimise the code in some way,
> > but it may not be &qu

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

Hi Olivier,

the approach you are attempting will not work for the reasons I described
previously.  If the message has (for instance) been placed in two durable
subscription queues (because there are two durable subscriptions) then as
soon as the message is consumed from the first queue it would be removed
from the store, leading to problems when the second consumer tries to read
the message.

-- Rob

On Mon, 17 Sep 2018 at 11:39, VERMEULEN Olivier 
wrote:

> Hello Rob,
>
> Thanks for the answer.
> I started looking at the code to see if there is something I can do about
> these 2 commits.
> But before going any further I'd like your input on the below, to see if
> what I'm trying to do could work or if I'm missing something (which I'm
> surely are)
>
> https://github.com/apache/qpid-broker-j/compare/master...overmeulen:feature/jdbc-message-store-commits
>
> Regards,
> Olivier
>
> -Original Message-
> From: Rob Godfrey 
> Sent: vendredi 14 septembre 2018 16:06
> To: users@qpid.apache.org
> Cc: AYOUBI Ali 
> Subject: Re: [Broker-J] JDBC message store performance
>
> On Fri, 14 Sep 2018 at 15:30, VERMEULEN Olivier <
> olivier.vermeu...@murex.com>
> wrote:
>
> > Hello,
> >
> > We ran a performance test with a bunch of brokers and an Oracle
> > database to store the messages.
> > We noticed that the database was a bit overloaded with commits.
> > Looking at the logs we saw that sending a message was triggering 1
> > commit for 3 operations (QPID_QUEUE_ENTRIES, QPID_MESSAGE_METADATA,
> > QPID_MESSAGE_CONTENT) which is what we were expecting but receiving a
> > message was triggering 2 commits (1 for QPID_QUEUE_ENTRIES and 1 for
> > QPID_MESSAGE_METADATA and QPID_MESSAGE_CONTENT).
> > I debugged a bit the code and saw that in
> > AbstractVirtualHost.executeTransaction the delete on
> > QPID_MESSAGE_METADATA and QPID_MESSAGE_CONTENT was defined as a "post
> > commit" operation, explaining why we have 2 commits.
> > Is it something expected? Do you think we could reduce this to 1
> > commit when receiving a message?
> >
>
> It's not unexpected - basically the issue is that the broker needs to cope
> with the possibility that the same message is being stored on multiple
> queues.  The first commit is deleting the referencing of the message from
> the given queue.  The second commit is occuring after the message has been
> definitively removed from the queue, and the store has determined that
> there are no more references, so it is ok to remove the message.  This is
> driven by reference-counting of the message, and has historically been a
> place of many potential race conditions.  I'm sure it is possible to
> optimise the code in some way, but it may not be "easy".  For the BDB store
> this doesn't matter as much as the actual synchronisation to disk of these
> operations is coalesced, obviously this is more of an issue for the JDBC
> store.
>
> -- Rob
>
>
> >
> > 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.
>

Re: [Broker-J] JDBC message store performance

[Rob Godfrey]

On Fri, 14 Sep 2018 at 15:30, VERMEULEN Olivier 
wrote:

> Hello,
>
> We ran a performance test with a bunch of brokers and an Oracle database
> to store the messages.
> We noticed that the database was a bit overloaded with commits.
> Looking at the logs we saw that sending a message was triggering 1 commit
> for 3 operations (QPID_QUEUE_ENTRIES, QPID_MESSAGE_METADATA,
> QPID_MESSAGE_CONTENT) which is what we were expecting but receiving a
> message was triggering 2 commits (1 for QPID_QUEUE_ENTRIES and 1 for
> QPID_MESSAGE_METADATA and QPID_MESSAGE_CONTENT).
> I debugged a bit the code and saw that in
> AbstractVirtualHost.executeTransaction the delete on QPID_MESSAGE_METADATA
> and QPID_MESSAGE_CONTENT was defined as a "post commit" operation,
> explaining why we have 2 commits.
> Is it something expected? Do you think we could reduce this to 1 commit
> when receiving a message?
>

It's not unexpected - basically the issue is that the broker needs to cope
with the possibility that the same message is being stored on multiple
queues.  The first commit is deleting the referencing of the message from
the given queue.  The second commit is occuring after the message has been
definitively removed from the queue, and the store has determined that
there are no more references, so it is ok to remove the message.  This is
driven by reference-counting of the message, and has historically been a
place of many potential race conditions.  I'm sure it is possible to
optimise the code in some way, but it may not be "easy".  For the BDB store
this doesn't matter as much as the actual synchronisation to disk of these
operations is coalesced, obviously this is more of an issue for the JDBC
store.

-- Rob


>
> 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.
>

Re: [Broker-J] Detect idle connections

[Rob Godfrey]

Hi Tomas,

I don't believe there is a way to do that currently, but it seems like a
useful feature - please raise a JIRA and we can see about adding that

-- Rob

On Fri, 14 Sep 2018 at 09:20, Vavricka  wrote:

> Hi,
>
> we would like to detect idle connections in Java Broker. I found out there
> is JSON key 'lastIoTime' in connection statistics. Value of key
> 'lastIoTime'
> is also changing when no messages was sent/received over connection
> (probably heartbeat).
>
> Is there any way to detect when was last message sent/received over
> connection?
>
> 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
>
>

Re: [VOTE] Release Qpid for Java 6.1.7

[Rob Godfrey]

+1

Compiled from source
Ran bdb and mms 0-9-1 and 0-10 test profiles
Started up the broker and poked around the management console a bit

-- Rob

On Thu, 30 Aug 2018 at 09:57, Keith W  wrote:

> 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: [Broker-J] HTTP management

[Rob Godfrey]

On Wed, 29 Aug 2018 at 17:21, VERMEULEN Olivier 
wrote:

> Hello,
>
> While working with the Broker-J HTTP management I found some strange
> behaviors, especially while binding a queue to an exchange.
>
>   *   If the exchange does not exist the creation of the binding returns
> 404 where I would expect a 5XX
>

I think 404 is reasonable here - the binding is data in the exchange object
- if the exchange does not exist then there is no resource to be modified.
The error here is certainly client side, error code 400 would also make
sense.


>   *   If the queue does not exist the creation of the binding returns 422
> where I would also expect a 5XX
>

Again there hasn't been an internal server error, the client has just asked
for something that is not "correct".  I think here it would probably be
better just to use error code 400 than 422.


>   *   If the "x-filter-jms-selector" has an incorrect value (for example
> "*") I get an HttpServerErrorException (and not a HttpClientErrorException
> like the other ones) and the binding is actually created even though this
> exception is raised...
>
> For the last one:
> POST http;//localhost:8080/api/latest/exchange/default/default/myTopic/bind
> {
> "destination":"myQueue",
> "bindingKey":"#",
> "arguments": {
> "x-filter-jms-selector":"*"
> }
> }
>

OK - this is incorrect, the request is bad (because the filter is
malformed) and so it should return a 4xx error - again 400 is probably the
most appropriate.  Also the binding should not be created.



>
> If you confirm these are not expected I can try to fix them
>
>
If you want to provide a patch for the last one, which is definitely a bug,
that would be great - thanks

-- Rob



> Regards,
> Olivier
>
> ***
>
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not
> the intended recipient you are not authorised to distribute, copy or use
> this e-mail or any attachment to it. Murex cannot guarantee that it is
> virus free and accepts no responsibility for any loss or damage arising
> from its use. If you have received this e-mail in error please notify
> immediately the sender and delete the original email received, any
> attachments and all copies from your system.
>

Re: [DISCUSS] Ending support for Java 7 in Proton-J

[Rob Godfrey]

+1 on ending support for Java 7 in Proton-J

Do we actually document anywhere which versions of Java we "support"/have
tested on for the various Java components?  On a cursory look through the
website and READMEs I didn't see anything, except for the AMQP 0-x JMS
client claiming to support "Java 7 and above",  in practice I doubt there
has been much "official" testing with anything above Java 8.  Inspecting
the pom files of other components showed that they required at least Java
8, I didn't immediatey spot much in the way of documentation.

-- Rob

On Wed, 8 Aug 2018 at 20:08, mibo  wrote:

> At least from my personal opinion I agree to end the support for Java 7.
> So Java 7 itself is also not supported anymore [1].
>
> Kind regards, Michael
>
> [1]: http://www.oracle.com/technetwork/java/javase/eol-135779.html
>
> > Am 08.08.2018 um 20:04 schrieb Robbie Gemmell  >:
> >
> > 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
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>