Re: BrokerJ + Oauth2 max frame size

[Dan Langford]

thank you
https://issues.apache.org/jira/browse/QPID-8648

On Fri, May 19, 2023 at 4:04 AM Robbie Gemmell 
wrote:

> The SASL process occurs first, before the Open frame. The Open frames
> are what carries each peers advertised max frame size, mainly aimed at
> later message deliveries. The AMQP 1.0 spec defines before this
> however that the SASL frames can be at-most the 'min max frame size',
> which is fixed at 512 bytes, with no way to negotiate anything larger.
>
> As you can probably tell, that presents a problem if things in the
> SASL negotiation want to be larger, such as is likely in e.g a newer
> XOAUTH2 mechanism that didnt exist when that decision was originally
> made.
>
> To simply allow some of these newer alternative mechs to work, it was
> decided to just allow things to exceed the 512byte limit since both
> sides would have to already agree on using a given mech to begin with,
> so doing an alternative like creating a custom multi-challenge
> batching sequence to shuffle the bytes wasnt really going to be adding
> much except significant complexity.
>
> It appears broker-j allows up to 4096, and you have now found
> something to exceed even that. It doesnt look like it allows
> configuring it, but increasing that seems to be the only option that
> would help here.
>
> On Thu, 18 May 2023 at 22:14, Dan Langford  wrote:
> >
> > we are exploring the use of Oauth2 with Qpid BrokerJ. We use okta but its
> > all openid and the keycloak provider seems like it might work for us. we
> > are referencing this confluence article about how to configure the qpid
> jms
> > client to update the token as it expires
> >
> >
> https://cwiki.apache.org/confluence/display/qpid/XOAUTH2+SASL+Mechanism+and+token+expiration
> >
> > oauth jwt tokens can be BIG!!!
> >
> > here is the error
> >
> > 2023-05-18T20:29:10,377Z WARN  [IO-/172.22.0.1:59090]
> > (o.a.q.s.p.v.f.FrameHandler) - Unexpected exception handling frame
> > org.apache.qpid.server.util.ConnectionScopedRuntimeException:
> > Connection is closed before being fully established: specified frame
> > size 5007 larger than maximum frame header size 4096
> > at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.closeConnection(AMQPConnection_1_0Impl.java:1172)
> > at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.handleError(AMQPConnection_1_0Impl.java:785)
> > at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:219)
> > at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.onReceive(AMQPConnection_1_0Impl.java:1309)
> > at
> >
> >
> > as we are exploring this the problem we are running into seems to be that
> > the SASL frames are too big. and when we configure the max frame size on
> > the connection string that isnt configured until the Open frame is
> received
> > but that all is after the SASL. im wondering if there is a way to
> configure
> > the max frame size of the SASL frames or if there is a way to configure
> the
> > default/initial max frame size of BrokerJ.
> >
> >
> https://github.com/apache/qpid-broker-j/blob/9.0.0/broker-plugins/amqp-1-0-protocol/src/main/java/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java#L188
> >
> > or did i misunderstand / misinterpret my error and should the SASL auth
> all
> > happen after the Open frame is sent? thanks
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

BrokerJ + Oauth2 max frame size

[Dan Langford]

we are exploring the use of Oauth2 with Qpid BrokerJ. We use okta but its
all openid and the keycloak provider seems like it might work for us. we
are referencing this confluence article about how to configure the qpid jms
client to update the token as it expires

https://cwiki.apache.org/confluence/display/qpid/XOAUTH2+SASL+Mechanism+and+token+expiration

oauth jwt tokens can be BIG!!!

here is the error

2023-05-18T20:29:10,377Z WARN  [IO-/172.22.0.1:59090]
(o.a.q.s.p.v.f.FrameHandler) - Unexpected exception handling frame
org.apache.qpid.server.util.ConnectionScopedRuntimeException:
Connection is closed before being fully established: specified frame
size 5007 larger than maximum frame header size 4096
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.closeConnection(AMQPConnection_1_0Impl.java:1172)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.handleError(AMQPConnection_1_0Impl.java:785)
at 
org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:219)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.onReceive(AMQPConnection_1_0Impl.java:1309)
at


as we are exploring this the problem we are running into seems to be that
the SASL frames are too big. and when we configure the max frame size on
the connection string that isnt configured until the Open frame is received
but that all is after the SASL. im wondering if there is a way to configure
the max frame size of the SASL frames or if there is a way to configure the
default/initial max frame size of BrokerJ.

https://github.com/apache/qpid-broker-j/blob/9.0.0/broker-plugins/amqp-1-0-protocol/src/main/java/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java#L188

or did i misunderstand / misinterpret my error and should the SASL auth all
happen after the Open frame is sent? thanks

Re: [Broker-J] unable to AutoGenerate self signed on Java17

[Dan Langford]

thank you Daniil

On Tue, Feb 21, 2023 at 7:05 AM Daniil Kirilyuk 
wrote:

> Hi,
>
> JIRA QPID-8624 was created:
>
> https://issues.apache.org/jira/browse/QPID-8624
>
> Kind regards,
> Daniil Kirilyuk
>
>
> On Thu, Feb 16, 2023, 09:08 Daniil Kirilyuk 
> wrote:
>
> > Hi,
> >
> >  Although QPID Broker-J 9.0 is intended to be run on the Java 11
> > environment, we try to make it compatible with Java 17 as well. It
> > seems that the tests for the described functionality lack. Could you
> > please create a JIRA for this issue?
> >
> > As a workaround the mentioned JVM flags can be used, namely:
> >
> > --add-opens java.base/sun.security.tools.keytool=ALL-UNNAMED
> > --add-opens java.base/sun.security.x509=ALL-UNNAMED
> >
> > Kind regards,
> > Daniil Kirilyuk
> >
> > On Thu, 16 Feb 2023 at 01:22, Dan Langford 
> wrote:
> > >
> > > I have run QPID Broker-J 9.0 on openjdk17 for mac as well as temurin17
> > for
> > > linux. in both when i try to AutoGenerate a keystore with self signed
> > cert
> > > i get the following error:
> > >
> > > org.apache.qpid.server.configuration.IllegalConfigurationException:
> > > Unable to construct keystore
> > > at
> >
> org.apache.qpid.server.security.AutoGeneratedSelfSignedKeyStoreImpl.generatePrivateKeyAndCertificate(AutoGeneratedSelfSignedKeyStoreImpl.java:296)
> > > at
> >
> org.apache.qpid.server.security.AutoGeneratedSelfSignedKeyStoreImpl.postResolve(AutoGeneratedSelfSignedKeyStoreImpl.java:169)
> > > ...
> > >
> > > Caused by: java.lang.IllegalAccessException: class
> > > org.apache.qpid.server.transport.network.security.ssl.SSLUtil cannot
> > > access class sun.security.tools.keytool.CertAndKeyGen (in module
> > > java.base) because module java.base does not export
> > > sun.security.tools.keytool to unnamed module @6b37576e
> > > at
> >
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Unknown
> > > Source)
> > > at java.base/java.lang.reflect.AccessibleObject.checkAccess(Unknown
> > Source)
> > >...
> > >
> > >
> > > now i think i can start java with some flags to make some necessary
> > > classes available however i feel like this behavior is likely
> > > unintended.
> > >
> > > should users of Broker-J be expected to add runtime arguments to their
> > > java process to generate the keystore? or is there some other config I
> > > need for this to work? or is this an issue i should log in Jira?
> > >
> > >
> > > in Java11 this works great.
> >
>

Re: [Broker-J 6.1+] ACL+LDAP requires full DN?

[Dan Langford]

thank you for creating the issue. ill add a few comments to that in case
they prove helpful.

On Tue, Feb 21, 2023 at 7:17 AM Daniil Kirilyuk 
wrote:

> Hi,
>
> JIRA QPID-8625 was created:
>
> https://issues.apache.org/jira/browse/QPID-8625
>
> Kind regards,
> Daniil Kirilyuk
>
>
> On Fri, Feb 10, 2023, 08:23 Daniil Kirilyuk 
> wrote:
>
> > Hi,
> >
> > The LDAP authentication in qpid-broker-j is performed by
> > SimpleLDAPAuthenticationManagerImpl, which first tries to find the
> > user using supplied search value and then performs LDAP bind using the
> > DN found. Full DN is used as a principal name after that. There is a
> > flag "isBindWithoutSearch", but when set to true it would require to
> > supply full DN as the username (and wouldn't solve the ACL rules
> > issue).
> >
> > I would say, the current implementation doesn't support the desired
> > behavior. You could create a JIRA for this issue.
> >
> > Kind regards,
> > Daniil Kirilyuk
> >
> > On Wed, 8 Feb 2023 at 23:02, Dan Langford  wrote:
> > >
> > > We are upgrading some very old qpid servers in the enterprise (6.0.8)
> and
> > > we use LDAP authentication. Where I might have a current ACL entry like
> > > this:
> > >
> > > ACL ALLOW danlangford ALL
> > >
> > > im finding in QPID 6.1-9.0 i am needing the rule to look like this
> > >
> > > ACL ALLOW "cn=danlangford,ou=000,ou=People,o=MyEnterprise" ALL
> > >
> > > now in the above example i can still authenticate over HTTP or AMQP
> with
> > > the user "danlangford" and i see a log message
> > > Found 'danlangford' DN 'cn=danlangford,ou=000,ou=People,o=MyEnterprise'
> > > but my ACLs are now going to be much more verbose, and problematic (see
> > > below), if they have to contain the full DN.
> > >
> > > This is particularly problematic in my enterprise because our identity
> > team
> > > has partitioned out all the users. see the "ou=000" (i happen to be in
> > the
> > > first partition). so as it stands we will need to update our ACLs and
> go
> > > look up the full DN for each user manually to put into the ACL. And my
> > > identity team said that there is no guarantee that the partition won't
> > > change for some reason in the future and they encourage all system to
> > > search for a user. (cn=username) with search context of
> > > ou=People,o=MyEnterprise
> > >
> > > Is there a way to configure to prior behavior that allowed just the
> > > username in the ACL?
> >
>

[Broker-J] unable to AutoGenerate self signed on Java17

[Dan Langford]

I have run QPID Broker-J 9.0 on openjdk17 for mac as well as temurin17 for
linux. in both when i try to AutoGenerate a keystore with self signed cert
i get the following error:

org.apache.qpid.server.configuration.IllegalConfigurationException:
Unable to construct keystore
at 
org.apache.qpid.server.security.AutoGeneratedSelfSignedKeyStoreImpl.generatePrivateKeyAndCertificate(AutoGeneratedSelfSignedKeyStoreImpl.java:296)
at 
org.apache.qpid.server.security.AutoGeneratedSelfSignedKeyStoreImpl.postResolve(AutoGeneratedSelfSignedKeyStoreImpl.java:169)
...

Caused by: java.lang.IllegalAccessException: class
org.apache.qpid.server.transport.network.security.ssl.SSLUtil cannot
access class sun.security.tools.keytool.CertAndKeyGen (in module
java.base) because module java.base does not export
sun.security.tools.keytool to unnamed module @6b37576e
at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Unknown
Source)
at java.base/java.lang.reflect.AccessibleObject.checkAccess(Unknown Source)
   ...


now i think i can start java with some flags to make some necessary
classes available however i feel like this behavior is likely
unintended.

should users of Broker-J be expected to add runtime arguments to their
java process to generate the keystore? or is there some other config I
need for this to work? or is this an issue i should log in Jira?


in Java11 this works great.

[Broker-J 6.1+] ACL+LDAP requires full DN?

[Dan Langford]

We are upgrading some very old qpid servers in the enterprise (6.0.8) and
we use LDAP authentication. Where I might have a current ACL entry like
this:

ACL ALLOW danlangford ALL

im finding in QPID 6.1-9.0 i am needing the rule to look like this

ACL ALLOW "cn=danlangford,ou=000,ou=People,o=MyEnterprise" ALL

now in the above example i can still authenticate over HTTP or AMQP with
the user "danlangford" and i see a log message
Found 'danlangford' DN 'cn=danlangford,ou=000,ou=People,o=MyEnterprise'
but my ACLs are now going to be much more verbose, and problematic (see
below), if they have to contain the full DN.

This is particularly problematic in my enterprise because our identity team
has partitioned out all the users. see the "ou=000" (i happen to be in the
first partition). so as it stands we will need to update our ACLs and go
look up the full DN for each user manually to put into the ACL. And my
identity team said that there is no guarantee that the partition won't
change for some reason in the future and they encourage all system to
search for a user. (cn=username) with search context of
ou=People,o=MyEnterprise

Is there a way to configure to prior behavior that allowed just the
username in the ACL?

Re: Qpid Jms Client 0.35.0 problem reading message after some message redeliveries

[Dan Langford]

thank you i will reach out to the apache activemq artemis team.

On Mon, Aug 13, 2018 at 6:56 AM Robbie Gemmell 
wrote:

> Theres a couple things going on. The main/first issue is the data
> coming from the broker, those extra 3 bytes you noted in the counts.
>
> They are located within the payload just after the AMQP header, and
> represent an encoded null followed by the typecode for a smalluint,
> but that is then followed seemingly not by a uint value but rather by
> the same remaining byte payload as in the original sending of the
> message. The encoded null within the transfer payload causes the
> message to present in decode as not having further content after the
> header, which can be considered a bug in proton-j. Essentially though
> the problem started when the broker sent a corrupt payload. The header
> it sent was fully-populated in both cases and identifical, and the 3
> bytes sent after dont appear to represent anything complete (but what
> came after is fine), so I think this is a bug within the broker
> itself.
>
> The JMSXDeliveryCount value remained 2 because the client initially
> bases it on the amqp delivery-count within the message, and that didnt
> change as the message was 'released', which is what happened
> inbetween. I assume you threw an exception from onMessage to achieve
> that, and so that behaviour relates to
> https://issues.apache.org/jira/browse/QPIDJMS-388
>
> Robbie
>
> On 10 August 2018 at 23:53, Dan Langford  wrote:
> > TLDR messages redelivered from artemis broker get into state where qpid
> jms
> > client api will not show me the properties or body. trying to determine
> if
> > its the broker sending down bad data or if its the client not supporting
> > some frame structure
> >
> > I have a message on my broker right now (Artemis 2.6.2) its on a Queue
> > waiting to be delivered. I am connecting with Qpid Jms Client 0.35.0 and
> > the client is not revealing to me the properties or payload of the
> message.
> > below is my code. its using the simplified api we got in 2.0 (JmsContext)
> > to create a Consumer and the set a MessageListener. Then i do this on
> each
> > javax.jms.Message
> >
> >
> > for(Object name: Collections.list(message.getPropertyNames())) {
> > System.out.printf("property name=%s value=%s%n", name,
> > message.getObjectProperty((String) name));
> > }
> > System.out.printf("message payload=%s%n", message.getBody(String.class));
> > System.out.println("done");
> >
> >
> > and here are the frames i am seeing due to env variable PN_TRACE_FRM=true
> > (with some data scrubbed like hostnames)
> >
> >
> > [199721506:0] -> Open{
> > containerId='ID:12eea5d0-97f3-47d4-8d5a-e59c37452c10:1', hostname='
> > stage.myhost.org', maxFrameSize=1048576, channelMax=32767,
> > idleTimeOut=3, outgoingLocales=null, incomingLocales=null,
> > offeredCapabilities=null,
> > desiredCapabilities=[sole-connection-for-container, DELAYED_DELIVERY,
> > ANONYMOUS-RELAY, SHARED-SUBS], properties={product=QpidJMS,
> version=0.35.0,
> > platform=JVM: 1.8.0_181, 25.181-b13, Oracle Corporation, OS: Mac OS X,
> > 10.13.6, x86_64}}
> > [199721506:0] <- Open{ containerId='node1', hostname='null',
> > maxFrameSize=131072, channelMax=65535, idleTimeOut=3,
> > outgoingLocales=null, incomingLocales=null,
> > offeredCapabilities=[sole-connection-for-container, DELAYED_DELIVERY,
> > SHARED-SUBS, ANONYMOUS-RELAY], desiredCapabilities=null,
> > properties={product=apache-activemq-artemis,
> > failover-server-list=[{hostname=node1, scheme=amqp, port=61616,
> > network-host=node2}], version=2.6.2}}
> > [199721506:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> > incomingWindow=2047, outgoingWindow=2147483647 <(214)%20748-3647>,
> handleMax=65535,
> > offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [199721506:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
> > incomingWindow=2147483647 <(214)%20748-3647>, outgoingWindow=2147483647
> <(214)%20748-3647>, handleMax=65535,
> > offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [199721506:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> > incomingWindow=2047, outgoingWindow=2147483647 <(214)%20748-3647>,
> handleMax=65535,
> > offeredCapabilities=null, desiredCapabilities=null, properties=null}
> > [199721506:1] <- Begin{remoteChannel=1, nextOutgoingId=1,
> > incomingWindow=2147483647 <(214)%20748-3647>, outgoingWindow=2147483647
> <(214)%20748-3647>, handleMax=65535,
> > offered

Qpid Jms Client 0.35.0 problem reading message after some message redeliveries

[Dan Langford]

TLDR messages redelivered from artemis broker get into state where qpid jms
client api will not show me the properties or body. trying to determine if
its the broker sending down bad data or if its the client not supporting
some frame structure

I have a message on my broker right now (Artemis 2.6.2) its on a Queue
waiting to be delivered. I am connecting with Qpid Jms Client 0.35.0 and
the client is not revealing to me the properties or payload of the message.
below is my code. its using the simplified api we got in 2.0 (JmsContext)
to create a Consumer and the set a MessageListener. Then i do this on each
javax.jms.Message


for(Object name: Collections.list(message.getPropertyNames())) {
System.out.printf("property name=%s value=%s%n", name,
message.getObjectProperty((String) name));
}
System.out.printf("message payload=%s%n", message.getBody(String.class));
System.out.println("done");


and here are the frames i am seeing due to env variable PN_TRACE_FRM=true
(with some data scrubbed like hostnames)


[199721506:0] -> Open{
containerId='ID:12eea5d0-97f3-47d4-8d5a-e59c37452c10:1', hostname='
stage.myhost.org', maxFrameSize=1048576, channelMax=32767,
idleTimeOut=3, outgoingLocales=null, incomingLocales=null,
offeredCapabilities=null,
desiredCapabilities=[sole-connection-for-container, DELAYED_DELIVERY,
ANONYMOUS-RELAY, SHARED-SUBS], properties={product=QpidJMS, version=0.35.0,
platform=JVM: 1.8.0_181, 25.181-b13, Oracle Corporation, OS: Mac OS X,
10.13.6, x86_64}}
[199721506:0] <- Open{ containerId='node1', hostname='null',
maxFrameSize=131072, channelMax=65535, idleTimeOut=3,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[sole-connection-for-container, DELAYED_DELIVERY,
SHARED-SUBS, ANONYMOUS-RELAY], desiredCapabilities=null,
properties={product=apache-activemq-artemis,
failover-server-list=[{hostname=node1, scheme=amqp, port=61616,
network-host=node2}], version=2.6.2}}
[199721506:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[199721506:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[199721506:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[199721506:1] <- Begin{remoteChannel=1, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[199721506:1] ->
Attach{name='qpid-jms:receiver:ID:36414498-1cef-45b7-9829-65adf6b870b4:1:1:1:QUE-134b55356db040f68dd2f51413c1895c',
handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='QUE-134b55356db040f68dd2f51413c1895c', durable=NONE,
expiryPolicy=LINK_DETACH, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=[queue]},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[199721506:1] <-
Attach{name='qpid-jms:receiver:ID:36414498-1cef-45b7-9829-65adf6b870b4:1:1:1:QUE-134b55356db040f68dd2f51413c1895c',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='QUE-134b55356db040f68dd2f51413c1895c', durable=NONE,
expiryPolicy=LINK_DETACH, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=[queue]},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[199721506:1] -> Flow{nextIncomingId=1, incomingWindow=2047,
nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
linkCredit=1, available=null, drain=false, echo=false, properties=null}
[199721506:1] <- Transfer{handle=0, deliveryId=0, deliveryTag=\x00,
messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (416) "\x00Sp\xc0\x0b\x05A@p
\x00\x00\x03\xe8@R\x01@R

[broker-j 7.0.3] TTL expire to alt binding

[Dan Langford]

is there way to configure the broker to treat TTL expired messages as other
"undeliverable" messages by delivering those to the configured Alternate
Binding?

Re: Dispatch Router load balancing config questions

[Dan Langford]

thank you. as i configure this Messaging service i am now for fully
understanding why Azure Service Bus and RabbitMQ do not support
Transactions and Message Selectors :-)

Question about prefetch/acquired messages: i am finding that QDR will leave
some (up to 250 quite frequently) messages as acquired on the broker. or in
artemis terms "delivering". how would I go about configuring QDRs Prefetch
to keep it low? (considering the above configuration which is a simple
message routing config for load balancing / sharding behavior)

On Wed, Aug 9, 2017 at 10:06 AM Gordon Sim <g...@redhat.com> wrote:

> On 09/08/17 16:59, Dan Langford wrote:
> > back from vacation now. i upgraded to 0.8.0 and local/session
> transactions
> > look like they are working as expected.
> >
> > *Question about JMS filters / message selectors*: when i connect to my
> > artemis broker with the artemis client JMS filters work. when i connect
> to
> > my artemis broker with qpid-jms-client then jms filters work. HOWEVER
> when
> > i connect to THROUGH the dispatch routers with the qpid-jms-client the
> jms
> > filters (configured in the client code) seem to be ignored or lost. i
> > receive messages as if no filter was supplied. does QPID dispatch router
> > support filters configured programmatically via the client? with my
> > aforementioned configuration
> > https://gist.github.com/danlangford/4944dcc6c0d2703ffb8555603ed27340
> would
> > you expect jms filters to work?
>
> Filters/selectors will not work in conjunction with message routing,
> because the broker is unaware of the actual consumers. To allow
> filters/selectors (or other link specific features), you would need to
> use link routing. However it is the message routing behaviour that
> provides the simple load balancing for queues.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Dispatch Router load balancing config questions

[Dan Langford]

back from vacation now. i upgraded to 0.8.0 and local/session transactions
look like they are working as expected.

*Question about JMS filters / message selectors*: when i connect to my
artemis broker with the artemis client JMS filters work. when i connect to
my artemis broker with qpid-jms-client then jms filters work. HOWEVER when
i connect to THROUGH the dispatch routers with the qpid-jms-client the jms
filters (configured in the client code) seem to be ignored or lost. i
receive messages as if no filter was supplied. does QPID dispatch router
support filters configured programmatically via the client? with my
aforementioned configuration
https://gist.github.com/danlangford/4944dcc6c0d2703ffb8555603ed27340 would
you expect jms filters to work?

On Wed, Aug 2, 2017 at 9:46 AM Dan Langford <danlangf...@gmail.com> wrote:

> Thank you all very much. i will upgrade to dispatch router 0.8.0 and
> forget about XA transactions. i was thinking that all of these brokers out
> there support XA transactions and i am now realizing that they support XA
> on protocols that are not AMQP 1.0. in the past few days i have also
> studied more about XA and realize that for all of my clients they do not
> need transactions or that the local transactions will be just great.
>
> On Wed, Aug 2, 2017 at 4:43 AM Robbie Gemmell <robbie.gemm...@gmail.com>
> wrote:
>
>> On 1 August 2017 at 22:20, Dan Langford <danlangf...@gmail.com> wrote:
>> > ( github gist with all the config and data from the Original Post
>> > https://gist.github.com/danlangford/4944dcc6c0d2703ffb8555603ed27340 )
>> >
>> > YES i was under pretty light load. a couple hundred or thousand
>> messages at
>> > a time were all getting funneled into the local broker. You are right
>> once
>> > i got 7 or 8 simultaneous connections all pushing in a couple million
>> > message i started to see the load overflow to the other router and
>> broker.
>> > about 10% of messages in my setup were overflowing. thank you for your
>> > patience. I think this config is going to work great. i do think i just
>> > need a small adjustment to how i think about load balancing. when the
>> cost
>> > was the same to each broker then i would get approx 50/50 split (that
>> was
>> > when each router connected to each broker). with this setup where the
>> local
>> > cost is less its more like "balancing out once under load" and not the
>> > traditional "balance evenly to avoid load". but now that i understand
>> this
>> > its fine and i know what behavior to expect.
>> >
>> > so I do have some producers and consumers that need to use session
>> > transactions. we have seen those work fine over amqp1.0 when connected
>> to a
>> > QPID Broker or Artemis broker. but with the config you see here
>> connecting
>> > to a qpid dispatch router (directly or through our VIP) I cannot create
>> a
>> > session with "transacted=true". I get a NullPointerException
>> >
>> > javax.jms.JMSException: java.lang.NullPointerException
>> > at
>> >
>> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:86)
>> > at
>> >
>> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:108)
>> > at
>> org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:609)
>> > at
>> >
>> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:125)
>> > at org.apache.qpid.jms.JmsSession.(JmsSession.java:143)
>> > at
>> org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:299)
>> > at org.myorg.mymessaging.PostOffice.buildSession(PostOffice.java:149)
>> > ...
>> > Caused by: java.io.IOException: java.lang.NullPointerException
>> > at
>> >
>> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
>> > at
>> >
>> org.apache.qpid.jms.provider.amqp.AmqpTransactionCoordinator.processDeliveryUpdates(AmqpTransactionCoordinator.java:117)
>> > at
>> >
>> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:928)
>> > at
>> >
>> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1800(AmqpProvider.java:93)
>> > at
>> >
>> org.apache.qpid.jms.provider.amqp.AmqpProvider$18.run(AmqpProvider.java:790)
>> > at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> >

Re: Dispatch Router load balancing config questions

[Dan Langford]

Thank you all very much. i will upgrade to dispatch router 0.8.0 and forget
about XA transactions. i was thinking that all of these brokers out there
support XA transactions and i am now realizing that they support XA on
protocols that are not AMQP 1.0. in the past few days i have also studied
more about XA and realize that for all of my clients they do not need
transactions or that the local transactions will be just great.

On Wed, Aug 2, 2017 at 4:43 AM Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:

> On 1 August 2017 at 22:20, Dan Langford <danlangf...@gmail.com> wrote:
> > ( github gist with all the config and data from the Original Post
> > https://gist.github.com/danlangford/4944dcc6c0d2703ffb8555603ed27340 )
> >
> > YES i was under pretty light load. a couple hundred or thousand messages
> at
> > a time were all getting funneled into the local broker. You are right
> once
> > i got 7 or 8 simultaneous connections all pushing in a couple million
> > message i started to see the load overflow to the other router and
> broker.
> > about 10% of messages in my setup were overflowing. thank you for your
> > patience. I think this config is going to work great. i do think i just
> > need a small adjustment to how i think about load balancing. when the
> cost
> > was the same to each broker then i would get approx 50/50 split (that was
> > when each router connected to each broker). with this setup where the
> local
> > cost is less its more like "balancing out once under load" and not the
> > traditional "balance evenly to avoid load". but now that i understand
> this
> > its fine and i know what behavior to expect.
> >
> > so I do have some producers and consumers that need to use session
> > transactions. we have seen those work fine over amqp1.0 when connected
> to a
> > QPID Broker or Artemis broker. but with the config you see here
> connecting
> > to a qpid dispatch router (directly or through our VIP) I cannot create a
> > session with "transacted=true". I get a NullPointerException
> >
> > javax.jms.JMSException: java.lang.NullPointerException
> > at
> >
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:86)
> > at
> >
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:108)
> > at
> org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:609)
> > at
> >
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:125)
> > at org.apache.qpid.jms.JmsSession.(JmsSession.java:143)
> > at
> org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:299)
> > at org.myorg.mymessaging.PostOffice.buildSession(PostOffice.java:149)
> > ...
> > Caused by: java.io.IOException: java.lang.NullPointerException
> > at
> >
> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
> > at
> >
> org.apache.qpid.jms.provider.amqp.AmqpTransactionCoordinator.processDeliveryUpdates(AmqpTransactionCoordinator.java:117)
> > at
> >
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:928)
> > at
> >
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1800(AmqpProvider.java:93)
> > at
> >
> org.apache.qpid.jms.provider.amqp.AmqpProvider$18.run(AmqpProvider.java:790)
> > at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at
> >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> > at
> >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:748)
> > Caused by: java.lang.NullPointerException
> > at
> >
> org.apache.qpid.jms.provider.amqp.AmqpTransactionCoordinator.processDeliveryUpdates(AmqpTransactionCoordinator.java:93)
> > ... 10 more
> >
>
> I've raised https://issues.apache.org/jira/browse/QPIDJMS-307 to
> investigate this and improve the handling. Though it did fail to
> create the session, as it should have given Gordon's earlier
> explanation, it didn't do it very well so there is definitely a client
> bug there. Possibly also a router one if my hunch of what happened is
> accurate.
>
> > are transactions 

Re: Dispatch Router load balancing config questions

[Dan Langford]

( github gist with all the config and data from the Original Post
https://gist.github.com/danlangford/4944dcc6c0d2703ffb8555603ed27340 )

YES i was under pretty light load. a couple hundred or thousand messages at
a time were all getting funneled into the local broker. You are right once
i got 7 or 8 simultaneous connections all pushing in a couple million
message i started to see the load overflow to the other router and broker.
about 10% of messages in my setup were overflowing. thank you for your
patience. I think this config is going to work great. i do think i just
need a small adjustment to how i think about load balancing. when the cost
was the same to each broker then i would get approx 50/50 split (that was
when each router connected to each broker). with this setup where the local
cost is less its more like "balancing out once under load" and not the
traditional "balance evenly to avoid load". but now that i understand this
its fine and i know what behavior to expect.

so I do have some producers and consumers that need to use session
transactions. we have seen those work fine over amqp1.0 when connected to a
QPID Broker or Artemis broker. but with the config you see here connecting
to a qpid dispatch router (directly or through our VIP) I cannot create a
session with "transacted=true". I get a NullPointerException

javax.jms.JMSException: java.lang.NullPointerException
at
org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:86)
at
org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:108)
at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:609)
at
org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:125)
at org.apache.qpid.jms.JmsSession.(JmsSession.java:143)
at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:299)
at org.myorg.mymessaging.PostOffice.buildSession(PostOffice.java:149)
...
Caused by: java.io.IOException: java.lang.NullPointerException
at
org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
at
org.apache.qpid.jms.provider.amqp.AmqpTransactionCoordinator.processDeliveryUpdates(AmqpTransactionCoordinator.java:117)
at
org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:928)
at
org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1800(AmqpProvider.java:93)
at
org.apache.qpid.jms.provider.amqp.AmqpProvider$18.run(AmqpProvider.java:790)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at
org.apache.qpid.jms.provider.amqp.AmqpTransactionCoordinator.processDeliveryUpdates(AmqpTransactionCoordinator.java:93)
... 10 more

are transactions expected to work with qpid dispatch router? on that note
do you think i could also get XA transactions working? would i need to use
a link route? i dont know for sure but it sounds like a link route is a
little more low level that an autolink.

thank you

On Tue, Aug 1, 2017 at 6:47 AM Ted Ross <tr...@redhat.com> wrote:

> Dan,
>
> There's one issue with your configuration which doesn't affect the load
> balancing but will cause problems with receiving messages from the
> brokers.  In the address.prefix, you use "foo.#".  This is a pure prefix
> and it should simply be "foo".  The wildcards are coming in the next
> release but are not implemented in the code you are using.
>
> Regarding your actual question.  I assume that you are testing this
> configuration under light load (i.e. sending one message at a time).
>
> The way that the balancing works is that it will route to the consumer
> (broker) with the fewest outstanding deliveries + inter-router cost.  This
> means that it will favor the local broker over the remote one if there are
> no in-flight deliveries.  The default (and minimum) cost for an
> inter-router connection is 1.  You can set it to a higher value in the
> listener or connector.
>
> If you are sending one-at-a-time synchronous sends, they will always go to
> the local broker because the broker's zero outstanding deliveries will
> always be less than the inter-router cost of 1.  If you send multiple
> deliveries asynchronously, you will see them being distributed to both
> brokers in the network.  You can make the local-affinity stronger by
> increasing the inter-router

Dispatch Router load balancing config questions

[Dan Langford]

Last week I had a thread with lots of little questions around Dispatch
Routers. Ted Ross has been awesome to answer most of those. As a result I
feel like I have my QDR config shaping up a bit better. HOWEVER with some
more very focused questions I thought it would be best to start a new
thread. The problem I am seeing is that the routers are not distributing
the message load across other brokers on the network. Here is a little
diagram:


RouterA-03 > ArtemisBrokerA
 |
 |
 |
\/
RouterB-05 > ArtemisBrokerB


*NOTE: i am currently using Qpid Dispatch Router from a RHEL repo. v 0.7.0*


Connections from clients come in through an F5 VIP which forwards those
connections to either host L-03-A or L-05-B. Each of those hosts have a
Qpid Dispatch Router installed in front of an Artemis broker. dispatch
router on L-05-B is listening on an additional port that dispatch router
L-03-A connects to for inter-router communication.

If I go around my F5 VIP so i know I am connecting straight to L-05-B and I
send any number of messages into the router there all of those messages end
up in ArtemisBrokerB. I was hoping that some would go to BrokerB and some
would go via RouterA over to BrokerA. Now when BrokerB is taken down
CURRENTLY the messages sent to Router L-05-B ARE routed through Router
L-03-A and then out to ArtemisBrokerB. (Currently receiving messages pull
them in from both hosts so my questions only lies in message production at
the moment.)

Do you agree that with this configuration you would expect messages to be
load balanced between the two routes? I would like to paste in some of our
config and results from running qdstat. If you observe something that is
misconfigured and are able to highlight it i would be very appreciative.
First the config files for QDR instances. I tried my best to scrub them of
specific IPs and hostnames.

*L-03-A qrouterd.conf*


*router {*

*mode: interior*

*id: Router.A*

*}*

*log {*

*module: DEFAULT*

*enable: debug+*

*timestamp: yes*

*}*

*sslProfile {*

*name: my-ssl*

*certFile: /opt/org/my-ssl-info.pem*

*keyFile: /opt/org/my-ssl-info.pem*

*password: hellokitty42*

*}*

*listener {*

*role: normal*

*host: 0.0.0.0*

*port: 5671*

*authenticatePeer: no*

*saslMechanisms: ANONYMOUS*

*sslProfile: my-ssl*

*}*

*connector {*

*name: local-artemis*

*role: route-container*

*host: L-03-A*

*port: 61616*

*saslMechanisms: ANONYMOUS*

*}*

*connector {*

*name: routerb*

*role: inter-router*

*host: L-05-B*

*port: 6671*

*saslMechanisms: ANONYMOUS*

*}*

*address {*

*prefix: foo.#*

*waypoint: yes*

*distribution: balanced*

*}*

*autoLink {*

*addr: foo.bar*

*dir: in*

*connection: local-artemis*

*}*

*autoLink {*

*addr: foo.bar*

*dir: out*

*connection: local-artemis*

*}*


*L-05-B qrouterd.conf*

*router {*

*mode: interior*

*id: Router.B*

*}*

*log {*

*module: DEFAULT*

*enable: debug+*

*timestamp: yes*

*}*

*sslProfile {*

*name: my-ssl*

*certFile: /opt/org/my-ssl-info.pem*

*keyFile: /opt/org/my-ssl-info.pem*

*password: hellokitty42*

*}*

*listener {*

*role: normal*

*host: 0.0.0.0*

*port: 5671*

*authenticatePeer: no*

*saslMechanisms: ANONYMOUS*

*sslProfile: my-ssl*

*}*

*listener {*

*role: inter-router*

*host: 0.0.0.0*

*port: 6671*

*authenticatePeer: no*

*saslMechanisms: ANONYMOUS*

*sslProfile: my-ssl*

*}*

*connector {*

*name: local-artemis*

*role: route-container*

*host: L-05-B*

*port: 61616*

*saslMechanisms: ANONYMOUS*

*}*

*address {*

*prefix: foo.#*

*waypoint: yes*

*distribution: balanced*

*}*

*autoLink {*

*addr: foo.bar*

*dir: in*

*connection: local-artemis*

*}*

*autoLink {*

*addr: foo.bar*

*dir: out*

*connection: local-artemis*

*}*




*L-03-A ~]$ qdstat -b:5671 -g*

*Router Statistics*

*  attr   value*

*  =*

*  Mode   interior*

*  Area   0*

*  Router Id  Router.A*


*L-05-B ~]$ qdstat -b:5671 -g*

*Router Statistics*

*  attr   value*

*  =*

*  Mode   interior*

*  Area   0*

*  Router Id  Router.B*




*L-03-A ~]$ qdstat -b:5671 -c*

*Connections*

*  Id  host container role
dir  security authentication*

*
==*

*  14  L-03-A:61616 L-03-A
route-container  out  no-security  anonymous-user*

*  107132  L-05-B:6671  Router.B
inter-router out  no-security  anonymous-user*

*  107267  127.0.0.1:37916 
180851ba-7ce4-44d0-a937-97de16e781c4  normal   in   no-security
anonymous-user*


*L-05-B ~]$ qdstat -b:5671 -c*

*Connections*

*  Id   host

Re: Dispatch Router questions

[Dan Langford]

On Thu, Jul 20, 2017 at 9:58 AM Ted Ross <tr...@redhat.com> wrote:

> On Wed, Jul 19, 2017 at 7:36 PM, Dan Langford <danlangf...@gmail.com>
> wrote:
>
> > > - Can I configure QDR to autoLink in and out ANY/ALL addresses?
> > No.  There is no way currently for QDR to know what queues are present on
> > its connected brokers.  It would not be difficult to write a program to
> > synchronize autolinks to existing queues.
>

You are right it wouldn't be that difficult. Also with artemis I can turn
on autocreation of queues and then then use QDR as the spot to manage what
queues can exist. Not bad. What about synchronizing autoLink config across
routers in a QDR network? are messages to the $management queue broadcast
throughout the cluster? i could always resend the necessary messages
through the _topo address namespace to get it to the other routers.


> > > - Artemis doesn't support vhosts. Can I configure connections to
> vhost:Foo
> > > address:bar actually be address:Foo.bar when the message goes back to
> the
> > > broker?
> > Yes.  There is a multi-tenancy feature for listeners that does exactly
> what
> > you are asking for.  If you add the attribute "multiTenant: yes" to the
> > configuration of a listener in the qdrouterd.conf file, clients connected
> > via that listener will have their addresses annotated as vhost/addr in
> the
> > router.
>

ok this is going to be perfect.  i am starting to feel more comfortable
with everything in this config file

> > - Can I configure QDR to pass auth through to the broker and let the
> broker
> > > decide is the user is authenticated and authorized? Inversely can I
> > > configure QDR to be the only determinate of auth?
> > Presently, QDR expects to be the sole determiner of authentic identity.

> There is an open request to add a SASL proxy that might be used to allow
> > the broker to do authentication on behalf of the router, but that hasn't
> > made it into master yet.
>

this is one part that has me a little stuck. QDR is the sole determiner of
auth identity. but QDR delegates to a cyrus sasl config right? and cyrus
sasl has some local DB options or sql or ldap or it can delegate to
kerberos or pam and i am just starting to feel a little lost in all my auth
option because its been a long time since i have been through all that. i
will figure it out well enough. i kind of wish there was a way i could send
a message in through $management to add a new user/pass to the sasldb but
ill figure something out.

also, in regards to auth where is it that i specify what users have access
to what addresses? it looks like that might be in the config in
vhost>groups but then i see a policy area of the config. ill start in the
vhost>groups area and see how far i get


> > > I think depending on what I learn on these topics I will likely have
> more
> > > questions. Thank you to anybody who is able to give me a lead or point
> me
> > > to a config that may serve as an example. I really do appreciate it.
> > Please don't hesitate to ask more questions or point out where there is
> > lack of documentation.  We appreciate it as well.
>

so i had another question come up in my research today. i have a single F5
BIG IP VIP that sits in front of all my VMs that are across two different
geographic locations. due to the two locations i want, well, two of
everything in a way that i can use all the resources at my disposal but
still function if one location goes offline. So here are (R)outers and
(B)rokers in locations (a) and (b)

in order for me to be able to produce messages into Ba and Bb i found that
each one of my Routers needed a connection to each one of my Brokers.

Essentially:
Ra --> Ba
Ra --> Bb
Rb --> Ba
Rb --> Bb

Graphically:
Ra --- Ba
   \ /
   / \
Ra --- Bb

it was really cool that i could send messages to Ra and see them fill up
both Ba and Bb. Receiving across both brokers also worked. But i was hoping
for more of a configuration where the Routers where only connected to a
single Broker and all the Routers knew about each other.

Essentially:
Ra --> Ba
Rb --> Bb
Ra <-> Rb

Graphically:
Ra --- Ba
||
||
Ra --- Bb

but in this configuration messages sent to Ra only got routed to Ba and
when i made a consumer on Ra i could only get messages off of Ba. Do you
know what someone would need to do in the configuration to support this?
 or is this architecture not ideal? the next thing i was going to try was
to make the Cost of Ra --> Ba = 2 so that it was equal to the Cost of Ra
--> Rb --> Bb and then maybe they would be considered as equal routes and
messages would balance between them. i dont think this explains why i
couldnt consume from both.  ill work on that tomorrow maybe.

any ideas you might have would be cool. thanks again. i really appreciate
your insight

Dispatch Router questions

[Dan Langford]

So I am struggling to wrap my head around some dispatch Router concepts and
was wondering if somebody would be willing to point me in the right
direction on one or more of my idea.

Background: I am doing some due diligence at my place of employment
regarding AMQP1.0 brokers and currently I am trying to see what Artemis w/
HA, Colocation, and Replication looks like. Artemis does not currently
support load-balancing AMQP messages through its cluster and they suggested
I use QDR for that.

So as I tried to jump into QDR I just found myself lost on some of these
concepts and terms and I struggled finding examples, guides, or tutorials.
I am just wanting load balancing of incoming messages to two brokers. For
HA reasons I want 2 QDR nodes able to "front" these two brokers.  As it
currently stands here are my questions:

- Can I configure QDR to autoLink in and out ANY/ALL addresses?

- Artemis doesn't support vhosts. Can I configure connections to vhost:Foo
address:bar actually be address:Foo.bar when the message goes back to the
broker?

- Can I configure QDR to pass auth through to the broker and let the broker
decide is the user is authenticated and authorized? Inversely can I
configure QDR to be the only determinate of auth?

I think depending on what I learn on these topics I will likely have more
questions. Thank you to anybody who is able to give me a lead or point me
to a config that may serve as an example. I really do appreciate it.

Re: [Java Client JMS] qpid-jms-client 0.22.0 vs qpid-client 6.1.2: prefetch behaving differently

[Dan Langford]

Will you let me know if a Jira ticket is made as a result of this so I can
track which version gets an adjustment?

I did more testing around this and am convinced this is what caused our
Broker to get a Out Of Memory for Direct Memory. We saw our broker crashing
and our primary client of the large backed up queue also crashing due to
Memory issues. In my testing those problems went away with a prefetch of 1.
I think that when all the hundreds of thousands of messages were prefetched
both the client and broker where holding them in Memory and running out.
With prefetch = 1 we were able to push around millions with very little
problems

Thanks. I'm anxious for a Qpid JMS client I can encourage my customers to
upgrade to to avoid this in the future. Let me know if you would like me to
test any bug fixes
On Fri, May 5, 2017 at 8:34 AM Dan Langford <danlangf...@gmail.com> wrote:

> Thanks for the replies and the work around. Getting this working will be
> great as we mostly use the competing consumer approach here. When
> somebodies queue gets backed up to half a million messages they want to
> just scale out their instances in CloudFoundry to increase throughput.
> On Fri, May 5, 2017 at 7:09 AM Rob Godfrey <rob.j.godf...@gmail.com>
> wrote:
>
>> On 5 May 2017 at 14:14, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
>>
>> > I can also reproduce this. I believe it is a deficiency in how/when
>> > the client handles granting more link credit, and it will show
>> > particularly badly in the scenario described where the broker is able
>> > to significantly/totally use the existing credit between processing of
>> > individual messages and there is a backlog of queued messages to
>> > continuously feed the scenario.
>> >
>> > To work around the issue and achieve the effect you are looking for,
>> > of balancing the backlog between multiple consumers when some come up
>> > later than others, you will need to reduce the prefetch setting to 0
>> > or 1.
>> >
>> >
>> To be clear then, it is a bug in the JMS client rather than the broker :-)
>>
>> -- Rob
>>
>>
>> > Robbie
>> >
>> > On 5 May 2017 at 10:07, Keith W <keith.w...@gmail.com> wrote:
>> > > Hi Dan
>> > >
>> > > Thanks for the comprehensive report.  I can reproduce what you see and
>> > > confirm there appears to be a bug.  I'll hope to be able to take a
>> > > closer look later today or Monday and get back to you with more
>> > > information.
>> > >
>> > > Keith.
>> > >
>> > > On 4 May 2017 at 23:39, Dan Langford <danlangf...@gmail.com> wrote:
>> > >> So over the past few weeks we have had a huge influx of messages on
>> our
>> > >> enterprise message bus (qpid java 6.0.4 serves the AMQP1.0 messaging
>> > >> portion) and when one of our clients struggled scaling their
>> > application up
>> > >> it got us looking at prefetch. we thought it was odd that all 500k
>> > messages
>> > >> in the queue were prefetched and it was due to the prefetch that when
>> > they
>> > >> scaled out the new connections could help with those messages they
>> could
>> > >> only acquire new messages.
>> > >>
>> > >> so i started running tests on a local instance of qpid java 6.1.2
>> and i
>> > was
>> > >> able to duplicate the behavior which seems odd.
>> > >>
>> > >> Setup.
>> > >> my java code will use the JMS api to create a consumer,
>> receiveNoWait a
>> > >> message, acknowledge or commit the message, then Thread.sleep for a
>> bit
>> > to
>> > >> look at the Qpid Java Brokers web interface for stats around
>> prefetched
>> > >> messages.
>> > >>
>> > >> Test 1. qpid-jms-client 0.22.0 with prefetch of 10 set via jms url
>> > >> parameter (jms.prefetchPolicy.all=10) OR set via PreFetchPolicy on
>> the
>> > >> ConnectionFactory (jmsDefaultPrefetchPolicy.setAll(10);)
>> > >> After the first message came in the web interface showed the queue
>> size
>> > >> decrement and 19 messages pre-fetched
>> > >> after second message queue size decremented again and 28 messages are
>> > >> pre-fetched
>> > >> after third message queue size also decremented and 37 messages
>> > prefetched
>> > >> so on and so forth
>> > >>
>> > &

Re: [Java Client JMS] qpid-jms-client 0.22.0 vs qpid-client 6.1.2: prefetch behaving differently

[Dan Langford]

Thanks for the replies and the work around. Getting this working will be
great as we mostly use the competing consumer approach here. When
somebodies queue gets backed up to half a million messages they want to
just scale out their instances in CloudFoundry to increase throughput.
On Fri, May 5, 2017 at 7:09 AM Rob Godfrey <rob.j.godf...@gmail.com> wrote:

> On 5 May 2017 at 14:14, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
>
> > I can also reproduce this. I believe it is a deficiency in how/when
> > the client handles granting more link credit, and it will show
> > particularly badly in the scenario described where the broker is able
> > to significantly/totally use the existing credit between processing of
> > individual messages and there is a backlog of queued messages to
> > continuously feed the scenario.
> >
> > To work around the issue and achieve the effect you are looking for,
> > of balancing the backlog between multiple consumers when some come up
> > later than others, you will need to reduce the prefetch setting to 0
> > or 1.
> >
> >
> To be clear then, it is a bug in the JMS client rather than the broker :-)
>
> -- Rob
>
>
> > Robbie
> >
> > On 5 May 2017 at 10:07, Keith W <keith.w...@gmail.com> wrote:
> > > Hi Dan
> > >
> > > Thanks for the comprehensive report.  I can reproduce what you see and
> > > confirm there appears to be a bug.  I'll hope to be able to take a
> > > closer look later today or Monday and get back to you with more
> > > information.
> > >
> > > Keith.
> > >
> > > On 4 May 2017 at 23:39, Dan Langford <danlangf...@gmail.com> wrote:
> > >> So over the past few weeks we have had a huge influx of messages on
> our
> > >> enterprise message bus (qpid java 6.0.4 serves the AMQP1.0 messaging
> > >> portion) and when one of our clients struggled scaling their
> > application up
> > >> it got us looking at prefetch. we thought it was odd that all 500k
> > messages
> > >> in the queue were prefetched and it was due to the prefetch that when
> > they
> > >> scaled out the new connections could help with those messages they
> could
> > >> only acquire new messages.
> > >>
> > >> so i started running tests on a local instance of qpid java 6.1.2 and
> i
> > was
> > >> able to duplicate the behavior which seems odd.
> > >>
> > >> Setup.
> > >> my java code will use the JMS api to create a consumer, receiveNoWait
> a
> > >> message, acknowledge or commit the message, then Thread.sleep for a
> bit
> > to
> > >> look at the Qpid Java Brokers web interface for stats around
> prefetched
> > >> messages.
> > >>
> > >> Test 1. qpid-jms-client 0.22.0 with prefetch of 10 set via jms url
> > >> parameter (jms.prefetchPolicy.all=10) OR set via PreFetchPolicy on the
> > >> ConnectionFactory (jmsDefaultPrefetchPolicy.setAll(10);)
> > >> After the first message came in the web interface showed the queue
> size
> > >> decrement and 19 messages pre-fetched
> > >> after second message queue size decremented again and 28 messages are
> > >> pre-fetched
> > >> after third message queue size also decremented and 37 messages
> > prefetched
> > >> so on and so forth
> > >>
> > >> Test 2. qpid-client 6.1.2 with prefetch of 10 set via url param
> > >> maxprefetch='10'
> > >> After the first message came in the web interface showed the queue
> size
> > >> decrement and 10 messages pre-fetched
> > >> after second message queue size decremented again and still 10
> messages
> > are
> > >> pre-fetched
> > >> after third message queue size also decremented and still 10 messages
> > >> prefetched
> > >> so on and so forth
> > >>
> > >> could it be a link credit thing? could i not be understanding
> prefetch?
> > >> maybe jms.prefetchPolicy is not the same as maxprefetch?
> > >>
> > >> Frame logs are here
> > >> https://pastebin.com/4NHGCWEa
> > >
> > > -
> > > 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
> >
> >
>

[Java Client JMS] qpid-jms-client 0.22.0 vs qpid-client 6.1.2: prefetch behaving differently

[Dan Langford]

So over the past few weeks we have had a huge influx of messages on our
enterprise message bus (qpid java 6.0.4 serves the AMQP1.0 messaging
portion) and when one of our clients struggled scaling their application up
it got us looking at prefetch. we thought it was odd that all 500k messages
in the queue were prefetched and it was due to the prefetch that when they
scaled out the new connections could help with those messages they could
only acquire new messages.

so i started running tests on a local instance of qpid java 6.1.2 and i was
able to duplicate the behavior which seems odd.

Setup.
my java code will use the JMS api to create a consumer, receiveNoWait a
message, acknowledge or commit the message, then Thread.sleep for a bit to
look at the Qpid Java Brokers web interface for stats around prefetched
messages.

Test 1. qpid-jms-client 0.22.0 with prefetch of 10 set via jms url
parameter (jms.prefetchPolicy.all=10) OR set via PreFetchPolicy on the
ConnectionFactory (jmsDefaultPrefetchPolicy.setAll(10);)
After the first message came in the web interface showed the queue size
decrement and 19 messages pre-fetched
after second message queue size decremented again and 28 messages are
pre-fetched
after third message queue size also decremented and 37 messages prefetched
so on and so forth

Test 2. qpid-client 6.1.2 with prefetch of 10 set via url param
maxprefetch='10'
After the first message came in the web interface showed the queue size
decrement and 10 messages pre-fetched
after second message queue size decremented again and still 10 messages are
pre-fetched
after third message queue size also decremented and still 10 messages
prefetched
so on and so forth

could it be a link credit thing? could i not be understanding prefetch?
maybe jms.prefetchPolicy is not the same as maxprefetch?

Frame logs are here
https://pastebin.com/4NHGCWEa

[qpid java broker 6.1.x] enqueue/dequeue over HTTP?

[Dan Langford]

I am going through the HTTP API documentation and I just want to confirm
what I am seeing. Is there a portion of the API to enqueue and dequeue
messages via HTTP? I was hoping for some REST api like Google's TaskQueues
 that
include a "lease", "delete", and "insert" operations. Or maybe something
like Amazon SQS
with
actions "ReceiveMessage", "DeleteMessage", and "SendMessage". Or
Microsoft ServiceBus
or
ActiveMQ , or HornetQ

.

In the current QPID API I can see the ability to get the contents of a
message and delete but these seems very administrative and not intended for
general messaging. Am I missing something or is this just a feature that
does not exist? If its truly needed I can throw together a shim unless any
of you know of an existing one.

Thanks so much

[Java Broker 6.1.1, qpid-jms-client 0.20.0] Best match for SASL auth was: null

[Dan Langford]

*Software Versions*
Java Broker 6.1.1
qpid-jms-client 0.20.0


*When my Authentication Provider assigned to my AMQP port
is PlainPasswordFile then i am able to connect just fine:*

*RemoteURI *amqp://:5672?amqp.vhost=default

[AmqpProvider:(1):[amqp://:5672]] INFO
org.apache.qpid.jms.sasl.SaslMechanismFinder - Best match for SASL auth
was: SASL-SCRAM-SHA-256
[AmqpProvider:(1):[amqp://:5672]] INFO
org.apache.qpid.jms.JmsConnection - Connection
ID:d03c3e30-63af-42bd-959b-a673c6da798f:1 connected to remote Broker:
amqp://:5672
Message sent: {"key1":"value1"}


*However when my Authentication Provider assigned to my AMQP port is set
to Base64MD5PasswordFile or SCRAM-SHA-256 i get this error on the client:*

*RemoteURI *amqp://:5672?amqp.vhost=default

[AmqpProvider:(1):[amqp://:5672]] INFO
org.apache.qpid.jms.sasl.SaslMechanismFinder - Best match for SASL auth
was: null
[main] ERROR org.apache.qpid.jms.JmsConnection - Failed to connect to
remote at: amqp://:5672?amqp.vhost=default

javax.jms.JMSSecurityException: Could not find a suitable SASL mechanism
for the remote peer using the available credentials.

at
org.apache.qpid.jms.provider.amqp.AmqpSaslAuthenticator.handleSaslInit(AmqpSaslAuthenticator.java:145)
at
org.apache.qpid.jms.provider.amqp.AmqpSaslAuthenticator.authenticate(AmqpSaslAuthenticator.java:92)
at
org.apache.qpid.jms.provider.amqp.AmqpProvider.processSaslAuthentication(AmqpProvider.java:925)
at
org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:909)
at
org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1800(AmqpProvider.java:93)
at
org.apache.qpid.jms.provider.amqp.AmqpProvider$18.run(AmqpProvider.java:784)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

I presume there is some sort of config i am missing. Does this ring a bell?
Is there a direction i could be pointed in? maybe it has to do with the URL
pattern my client is using in the connection factory? or maybe i just
completely misunderstand how i should be configuring SASL mechanisms.

thank you

[Qpid Java Broker] ensure nondestructive via UI

[Dan Langford]

Is there a way via the web management ui to create a queue that ensures
clients are nondestructive? I see the rest interface but don't know if
there is a way I can use qpid.ensure_nondestructive_consumers argument
somehow via context variables. If it's possible via the web UI then my ops
team could more easily set up some queues in higher lanes.

Re: deploying Qpid via Cloud Foundry

[Dan Langford]

Thank you for the explanation. It is very helpful to understand the
combination of Authentication Provider and Group Provider. I think we use
LDAP and / or SAML so I am interested in the fact that the UAA is an OAuth2
server in front of other authentication sources. I figured out what URLs I
need so it looks like I just need to work with the CF team here and procure
a clientId.

Now I just need to wrap my head around that service to group mapping. I'll
dive into the API today to see if I can programmatically change that
mapping via HTTP API. Then try to add acl rules over HTTP as well. I think
I am headed towards a flow like this:

1) in CF user creates Qpid service
2) service broker creates virtual host
3) service broker adds serviceId to the Service-to-Group mapping
4) service broker adds rule to the rule based Access Control Provider

Then later...

5) user logs into Qpid interface
6) login done via oauth2 to cf uaa
7) group Provider determines what groups a user is in based on CF service
access
8) access control provider enforces the rules based on user group limiting
the user to see just his new Virtual Host

All that service broker work is one reason I was wondering if somebody has
already done some of it.

Thanks again
On Wed, Mar 1, 2017 at 5:35 AM Lorenz Quack <quack.lor...@gmail.com> wrote:

> Hello Dan,
>
> I cannot comment too much on what you have to do on the CloudFoundry
> (CF) side of things but I might be able to give some advice from the
> Qpid Broker for Java side.
>
> For authentication, the broker supports OAuth2 [1] which is also
> supported by CF [2].  Qpid uses the implicit grant flow.  In the
> OAuth2 AuthenticationProvider you need to specify the
> authorizationEndpointURI, tokenEndpointURI, clientId, clientSecret.
> These align with the OAuth2 specification.  Not part of the OAuth2
> spec are the identityResolverEndpointURI and identityResolverType
> attributes.  You will want to set the type to
> CloudFoundryIdentityResolver and the EndpointURI to the check token
> service [3].  This is responsible to turn an access token into a
> username which will be used for logging and a UserPrincipal using this
> name will be added to the Subject.
>
> For authorization the scenario envisioned is that you use the
> CloudFoundryDashboardManagement GroupProvider in conjunction with a
> AccessControlProvider.  In the GroupProvider you configure a
> serviceToManagementGroupMapping containing a JSON map from CF
> serviceInstanceId to Qpid management group name.  When a user logs in
> this GroupProvider will query the configured cloudFoundryEndpointURI
> using this [4] API to figure out whether the user has permissions to
> manage any of the serviceInstances in the map.  For each
> serviceInstance that the user has permissions to manage a
> GroupPrincipal with the name from the map will be added to the
> Subject.  You can then write ACLs in terms of these management groups
> to limit access to certain parts of the broker.  For example you could
> limit access to a specific VirtualHost.
>
> I'll attach a text file with a ASCII diagram showing the login process.
>
>
> I hope this helps to illuminate how we envision the broker being used
> in a CloudFoundry scenario.
>
> Kind regards,
> Lorenz
>
>
> [1]
>
> https://qpid.apache.org/releases/qpid-java-6.1.1/java-broker/book/Java-Broker-Security.html#Java-Broker-Security-OAuth2-Provider
> [2] https://docs.cloudfoundry.org/api/uaa/
> [3] https://docs.cloudfoundry.org/api/uaa/#check-token
> [4]
>
> https://apidocs.cloudfoundry.org/252/apps/retrieving_permissions_on_a_app.html
>
>
> On 01/03/17 05:29, Dan Langford wrote:
> > On the IRC channel last week rgodfrey mentioned that some of you may be
> > deploying Qpid via Cloud Foundry. I am exploring some of those ideas for
> > use at my place of employment and was wondering if I could pick your
> brain
> > a little bit on what that setup might look like. Please forgive me if my
> > questions sound a bit obvious or naive im a bit new to some of these
> > concepts.
> >
> > Initially I had not considered deploying Qpid via CloudFoundry. I was
> just
> > planning an integration with our on-prem CF. I need a service broker for
> > Qpid. Have any of you set up Qpid as a service in your CF setup? Did you
> > write the service broker layer? Or is there an open source one already
> > available? I have never written a service broker before so if you have
> any
> > tips in regards to Qpid and a service broker they would be welcome.
> >
> > What is your pattern for a Qpid service in CF? Do you have a CF service
> > representing a single Queue? Or representing a VirtualHost? or does a new
> > service spin up an independent instance of Qpid? Would

deploying Qpid via Cloud Foundry

[Dan Langford]

On the IRC channel last week rgodfrey mentioned that some of you may be
deploying Qpid via Cloud Foundry. I am exploring some of those ideas for
use at my place of employment and was wondering if I could pick your brain
a little bit on what that setup might look like. Please forgive me if my
questions sound a bit obvious or naive im a bit new to some of these
concepts.

Initially I had not considered deploying Qpid via CloudFoundry. I was just
planning an integration with our on-prem CF. I need a service broker for
Qpid. Have any of you set up Qpid as a service in your CF setup? Did you
write the service broker layer? Or is there an open source one already
available? I have never written a service broker before so if you have any
tips in regards to Qpid and a service broker they would be welcome.

What is your pattern for a Qpid service in CF? Do you have a CF service
representing a single Queue? Or representing a VirtualHost? or does a new
service spin up an independent instance of Qpid? Would it be feasible for a
service to represent a Vhost and be associated ~1:1 to a CF "space", making
it so a "space" named "project-a-non-prod" would have a VHost named the
same?

So with the recent addition of a GroupProvider that backed by a CF Service
dashboard could somebody explain how that flow works? Does CF provide a URL
to manage the service and that URL has an accessToken in it? Or does
accessing the web admin redirect over to another url for authorization and
then redirect the user back to the web admin? Does/Can this groupProvider
be used for system-to-system access? We call those "service accounts" at
work. Or is it more appropriate for mainly User access to the web admin
area?

How are you granting users access to a queue? I assume you are using the
HTTP api around RuleBased access control provider? or is that not needed
with proper use of the aforementioned GroupProvider?

Are you spinning up single instances of Qpid as apps in CF to be used in
isolation and for specific purposes? Or do you have many Qpid CF instances
forming a large HA network of brokers accessed via Dispatch Routers?

Are you using CF TCP Routing or strictly HTTP/WS access or just connecting
directly to the host or a Dispatch Router?

Thank you so much for taking the time to glance over this and offer any
help you can in my understanding. I apologize if it seems that i have not
done my homework yet. I will have more throughput in the coming weeks to
start playing with it more hands on I was just hoping to get an idea of a
good direction to get headed off in, one that already had proven success.

Dan '8bagels' Langford
UTC-0700