Re: content-type & interoperability between Java/JMS & Cpp/amqp

[Olivier Mallassi]

Robbie,

Sorry and just in case. Is this decision "included decision to remove those
and leave it as implementation detail " definitive? :)

cheers

On Thu, Oct 25, 2018 at 9:37 PM Olivier Mallassi 
wrote:

> Thanks Robbie.
> I understand "leave it as implementation detail since the concepts " as I
> should use my own custom header like myContentTypeHeader
>
> Am I right?
> What would you advice then?
>
> On Thu, Oct 25, 2018 at 6:11 PM Robbie Gemmell 
> wrote:
>
>> The JMS client does not currently allow (outside of perhaps using
>> reflection to access implementation details) manipulating or accessing
>> the content type and encoding fields. It doesnt support the
>> vendor-property you refer to below, and discussion since that old
>> mapping draft was written (by me) actually included decision to remove
>> those and leave it as implementation detail since the concepts are not
>> part of JMS.
>>
>> On Thu, 25 Oct 2018 at 16:45, Olivier Mallassi
>>  wrote:
>> >
>> > All,
>> >
>> > I am facing the following context and would need your help as I am not
>> able
>> > to fully understand it from specification & code perspectives.
>> >
>> > I need
>> > - to send/consume messages using JMS and consume/send messages using
>> > proton-c.
>> > and
>> > - my message can be of multiple types : application/json,
>> application/xml
>> > and binary based on protocolbuffer (so something like
>> application/protobuf
>> > but to be defined).
>> > I was expecting to use the amqp content-type (and content-encoding)
>> > headers. but I cannot see how to set them in JMS.
>> >
>> > My understanding of the "specification" (
>> >
>> https://www.oasis-open.org/committees/download.php/56418/amqp-bindmap-jms-v1.0-wd06.pdf
>> )
>> > is that (1) there is a default mapping based on the java.jms.Message
>> type
>> > and (2) we can use JMS AMQP CONTENT TYPE vendor specific properties to
>> > specify our content type.
>> > Am I right?
>> > My understanding from the JMS code (
>> >
>> https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/message/AmqpCodec.java#L414
>> )
>> > is that I cannot do (2). in fact I will fallback to ByteMessage with no
>> way
>> > of being able to distinguish between the potential content-types.
>> >
>> > What am I missing? Do you have any guidelines about how to do this?
>> >
>> > Thanks a lot for your help and apologies if I missed something obvious.
>> >
>> > Regards.
>> >
>> > olivier.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>

Re: content-type & interoperability between Java/JMS & Cpp/amqp

[Olivier Mallassi]

Thanks Robbie.
I understand "leave it as implementation detail since the concepts " as I
should use my own custom header like myContentTypeHeader

Am I right?
What would you advice then?

On Thu, Oct 25, 2018 at 6:11 PM Robbie Gemmell 
wrote:

> The JMS client does not currently allow (outside of perhaps using
> reflection to access implementation details) manipulating or accessing
> the content type and encoding fields. It doesnt support the
> vendor-property you refer to below, and discussion since that old
> mapping draft was written (by me) actually included decision to remove
> those and leave it as implementation detail since the concepts are not
> part of JMS.
>
> On Thu, 25 Oct 2018 at 16:45, Olivier Mallassi
>  wrote:
> >
> > All,
> >
> > I am facing the following context and would need your help as I am not
> able
> > to fully understand it from specification & code perspectives.
> >
> > I need
> > - to send/consume messages using JMS and consume/send messages using
> > proton-c.
> > and
> > - my message can be of multiple types : application/json, application/xml
> > and binary based on protocolbuffer (so something like
> application/protobuf
> > but to be defined).
> > I was expecting to use the amqp content-type (and content-encoding)
> > headers. but I cannot see how to set them in JMS.
> >
> > My understanding of the "specification" (
> >
> https://www.oasis-open.org/committees/download.php/56418/amqp-bindmap-jms-v1.0-wd06.pdf
> )
> > is that (1) there is a default mapping based on the java.jms.Message type
> > and (2) we can use JMS AMQP CONTENT TYPE vendor specific properties to
> > specify our content type.
> > Am I right?
> > My understanding from the JMS code (
> >
> https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/message/AmqpCodec.java#L414
> )
> > is that I cannot do (2). in fact I will fallback to ByteMessage with no
> way
> > of being able to distinguish between the potential content-types.
> >
> > What am I missing? Do you have any guidelines about how to do this?
> >
> > Thanks a lot for your help and apologies if I missed something obvious.
> >
> > Regards.
> >
> > olivier.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

content-type & interoperability between Java/JMS & Cpp/amqp

[Olivier Mallassi]

All,

I am facing the following context and would need your help as I am not able
to fully understand it from specification & code perspectives.

I need
- to send/consume messages using JMS and consume/send messages using
proton-c.
and
- my message can be of multiple types : application/json, application/xml
and binary based on protocolbuffer (so something like application/protobuf
but to be defined).
I was expecting to use the amqp content-type (and content-encoding)
headers. but I cannot see how to set them in JMS.

My understanding of the "specification" (
https://www.oasis-open.org/committees/download.php/56418/amqp-bindmap-jms-v1.0-wd06.pdf)
is that (1) there is a default mapping based on the java.jms.Message type
and (2) we can use JMS AMQP CONTENT TYPE vendor specific properties to
specify our content type.
Am I right?
My understanding from the JMS code (
https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/message/AmqpCodec.java#L414)
is that I cannot do (2). in fact I will fallback to ByteMessage with no way
of being able to distinguish between the potential content-types.

What am I missing? Do you have any guidelines about how to do this?

Thanks a lot for your help and apologies if I missed something obvious.

Regards.

olivier.

Re: Broker-J statistics

[Olivier Mallassi]

Hi Olivier

AFAIR, I looked at the code at the UI console a couple of months ago and
the throughput per queues / exchange is calculated with a diff between
total messages every sec.
This is done in the Js

I guess that should answer your need


Olivier.

On Thu 1 Feb 2018 at 11:34, Olivier VERMEULEN 
wrote:

> Hello,
>
> We are currently implementing a messaging cluster with dispatch-routers and
> Java brokers.
> To be able to use it in production we are required to provide a few
> statistics.
> I see that I can use the broker ReST API to query some statistics on the
> queues, exchanges,...
> One of the statistics we are asked to provide is a the throughput of
> messages and the throughput of data going in and out of a queue.
> The ReST API gives me the total number of messages and total size of data
> going
> in and out of the queue. But to be able to calculate a throughput I need a
> way to reset those statistics.
> I read something about that for Broker-J 6.1.X but didn't find any
> reference to it for version 7. Is it expected? Is this use case supported
> and if yes how?
>
> Thanks,
> Olivier
>

Re: Consumer affinity (JMSXGroupID), AMQP 1.0

[Olivier Mallassi]

Thanks all, it helps
I saw this https://issues.apache.org/jira/browse/QPID-5165 while running
the "test" but did not get the whole picture.

Indeed, w/ multiple brokers + multiple DR, ensuring the consistency of the
 mapping group-id / consumers looks tricky (at least to me)...especially if
you consider things like elasticity, network failures. no?

On Fri, Sep 29, 2017 at 4:10 PM, Adel Boutros <adelbout...@live.com> wrote:

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

Consumer affinity (JMSXGroupID), AMQP 1.0

[Olivier Mallassi]

Gentleman,

I will need your help.

I have a use case where I would like to guarantee "consumer affinity",
which is usually implemented using the JMSXGroupID (actually, I am sure it
was working w/ AMQP 0.10 clients but here I am using AMQP 1.0)

My test does the "classical" case:
for (i ... i < 100.)
  Message textMsg = new TextM
   textMsg.setStringProperty("JMSXGroupID", "groupA")
  MessageProducer.send(textMsg);

and I start two consumers (assuming only one would work).

What I observe is that both consumers are receiving messages, acting as
competing consumers. I also tried added the qpid.group_header_key property
to the queue but it does not change anything.


My setup is
- java broker 6.0.4 & 6.1.4
- java clients using qpid-jms 0.25.0 (AMQP 1.0)

Is this the expected behaviour? Any ideas?


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


thanks for your help

Regards.

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

So following your idea, I am now trying to connect client.

 python simpleSend.py -a amqp://localhost:20202//domain/subdomain/queue1 -m
1 (note the //)
on the client, I see the attach frame

 @attach(18)
[name="71e559bd-81f1-4512-9223-d226aa813bb7-/domain/subdomain/queue1",
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false],
target=@target(41) [address="/domain/subdomain/queue1", durable=0,
timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]


yet, usind qdstat

 qdstat -b localhost:20202 -a
Router Addresses
  class   addr  phs  distrib   in-proc  local  remote
 cntnr  in  out  thru  to-proc  from-proc

===
  local   $_management_internal  closest   10  0
0  0   00 00
  mobile  $management   0closest   10  0
0  2   00 20
  local   $managementclosest   10  0
0  0   00 00
  mobile  */domain*/subdomain/queue1  1balanced  00  0
  0  0   00 00
  mobile  */domain*/subdomain/queue1  0balanced  01  0
  0  0   00 00
  mobile  *domain/*subdomain/queue1   0balanced  00  0
  0  0   00 00
  local   temp.k1lchlMcGRfNM3N   balanced  01  0
0  0   00 00


note the /domain are created via autoLink (following the Alan's idea of
)

the third one (domain/subdomain w/o the first /) is created (and deleted)
when starting the python client (and stopping it).

Looks like the dispatch router is also normalizing incoming Adress
(independently of the number of /// by the way ;) )

On Fri, Apr 7, 2017 at 10:48 PM, Olivier Mallassi <
olivier.malla...@gmail.com> wrote:

> Crafty :)
>
> I have just ran quick tests and it helps establishing the link between the
> dispatch & broker (attach flow frames)
> I am yet not able to send messages (got the attach frame by the client get
> stuck) I have to digg into
>
> Do you want me to create a Jira on this?
>
> Thx
>
>
>
> On Fri, 7 Apr 2017 at 17:38, Alan Conway <acon...@redhat.com> wrote:
>
>> On Fri, 2017-04-07 at 17:08 +0200, Olivier Mallassi wrote:
>> >
>> > I am fine with the "//" as long as it is not considered as connection
>> > information :)
>> >
>>
>> Random thought: have you tried "addr" in the configuration file?
>>
>> "//" + "" + "/" + "/addr" == "/addr"
>>
>> I haven't tried it, I may be dreaming. It is definitely not the
>> solution, but maybe a useful temporary workaround.
>>
>> > > I think Ganesh is already working on that so I'll stop confusing
>> > > the
>> > > issue.
>> > >
>> > >
>> > >
>> >
>> >
>> > Let us know if this is the case, that would be great!!
>> >
>>
>>

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

Crafty :)

I have just ran quick tests and it helps establishing the link between the
dispatch & broker (attach flow frames)
I am yet not able to send messages (got the attach frame by the client get
stuck) I have to digg into

Do you want me to create a Jira on this?

Thx



On Fri, 7 Apr 2017 at 17:38, Alan Conway <acon...@redhat.com> wrote:

> On Fri, 2017-04-07 at 17:08 +0200, Olivier Mallassi wrote:
> >
> > I am fine with the "//" as long as it is not considered as connection
> > information :)
> >
>
> Random thought: have you tried "addr" in the configuration file?
>
> "//" + "" + "/" + "/addr" == "/addr"
>
> I haven't tried it, I may be dreaming. It is definitely not the
> solution, but maybe a useful temporary workaround.
>
> > > I think Ganesh is already working on that so I'll stop confusing
> > > the
> > > issue.
> > >
> > >
> > >
> >
> >
> > Let us know if this is the case, that would be great!!
> >
>
>

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

I hope the colored text will work.
cf. below


On Fri, Apr 7, 2017 at 4:40 PM, Alan Conway <acon...@redhat.com> wrote:

> I jumped into the middle of this, sorry for irrelevant answers.
>
> Short story: I agree with you.
> Long story:
>
> On Thu, 2017-04-06 at 23:38 +0200, Olivier Mallassi wrote:
>
> > I ran the following tests:
> >
> > Access the broker directly (globalAddressDomains=/domain/subdomain +
> > queue1)
> > From a JMS client, the jndi queue name must contain the "/" .
> > (e.g. jndi name --> queue.myQueueLookup = /domain/subdomain/queue1)
> >
> >
> [snip]
> >
> >
> > From python, the "//" is needed.
> >
> > python ./simpleSend.py -a localhost:5672//domain/subdomain/queue1
>
> That's what I thought, good!
>
> The dispatch router has been configured with address and autoLink to
> /domain/subdomain/queue1. The AMQP Adress is normalized, hence
> > removing the first "/"
> [snip]
>
> I missed this part - you're talking about dispatch modifying addresses
> from the configuration file, not from a client.
>

Indeed. there is no client connected here.
Yet, I tried this because of the python example above.


>
> > Nos the dispatch router is configured with address and autoLink to
> > //domain/subdomain/queue1 (double "/")
> [snip]
> >
> > the //domain is removed.
> >
>
> The original AMQP addressing draft (from when dispatch started) defined
>  special meaning for leading '//' - to indicate connection information
> like this:
>
> //host:port/addr
>
> I think that is why dispatch is removing //domain.
>

This is also my guess.
I tried looking at the code.
When the link is activated (route_control.c#161) in the
method qdr_auto_link_activate_CT,
the following line is executed (L 182) qdr_terminus_set_address(term,
[2]);. In that case, the key[2] contains M1subdomain/queue1. I was
trying to find where the "//domain" was removed. it may be in the
agent_config_auto_link.c#370 where the addr is parsed.



> The current AMQP addressing draft *never* includes connection
> information in the AMQP address - because of exactly this kind of
> confusion. Given the direction of the current draft and the fact that
> it is still not final, I agree that dispatch should not modify the
> configured addresses at all.
>

I am fine with the "//" as long as it is not considered as connection
information :)


> I think Ganesh is already working on that so I'll stop confusing the
> issue.
>
>
>
Let us know if this is the case, that would be great!!

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

 timeout=0,
dynamic=false], target=@target(41) [*address="subdomain/queue1*",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false],
initial-delivery-count=0]
Thu Apr  6 23:06:50 2017 SERVER (trace) [1]:RAW:
"\x00\x00\x00\x82\x02\x00\x00\x01\x00S\x12\xd0\x00\x00\x00r\x00\x00\x00\x0a\xa1\x16qd


the //domain is removed.


in both cases, the Link between the dispatch router & the broker cannot be
established (just after I see a @detach frame)


Is my understanding correct?
Is the removal of //domain the expected behavior? could we imagine having
something similar to the python example above? hence, the address
normalization would not be the same between qpid-dispatch-router &
qpid-java-broker but at least, it could work.

Thx.

olivier.













On Thu, Apr 6, 2017 at 9:03 PM, Alan Conway <acon...@redhat.com> wrote:

> On Thu, 2017-04-06 at 05:50 +, Olivier Mallassi wrote:
> > Or is do we add a concept of globalAddressDomains at the level of the
> > vhost?
> > And have something similar to the qpid broker.
> >
> > Again the need is to address amqp destination like
> > amqp://ip:5672/domain/subdomain/dest
> > amqp://ip:5672/domain2/subdomain2/dest
> >
>
> I think is confusion between an AMQP address and a URL. The URL grammar
> is defined by https://tools.ietf.org/html/rfc3986. Parsing this URL:
>
> amqp://ip:5672/domain/subdomain/dest
>
> gives:
>
> scheme="amqp"
> host="ip"
> port="5672"
> path="domain/subdomain/dest"
>
> Note there is no leading "/" on the path. The "/" in the URL is part of
> the URL grammar, not part of the path. Dispatch is not stripping the
> leading '/' - there isn't one. Dispatch could *add* a leading "/" but
> then you couldn't write a URL for an address that *doesn't* have a
> leading slash (e.g. the standard "$management" address would become
> "/$management")
>
> This might work:
>
> amqp://ip:5672//domain/subdomain/dest
>
> Note the double '//'.
>
> Doubling slashes looks odd but there is precedent, in standard file URI
> (https://tools.ietf.org/html/rfc8089) Sadly lots of people find that
> confusing (file:///foo vs. file://foo) but  I can't think of a better
> solution. You could try URL percent-encoding:
>
> amqp://ip:5672/%2Fdomain/subdomain/dest
>
> But that's just hideous
>
> Note this is not a dispatch problem, it's a general "how do you embed
> an AMQP address in a URL problem"
>
> Apologies if I'm missing the point.
>
> > Thx
> >
> >
> > On Wed, 5 Apr 2017 at 11:48, Olivier Mallassi <olivier.mallassi@gmail
> > .com> wrote:
> > > Sorry Ganesh about this, my qdstat was in 0.5.0 :/
> > >
> > > I have retried the antoine's test with the following configuration
> > >
> > > address {
> > > prefix: /domain/subdomain/queue1
> > > waypoint: yes
> > > }
> > > connector {
> > > name: broker1
> > > role: route-container
> > > host: localhost
> > > port: 5672
> > > saslMechanisms: ANONYMOUS
> > > }
> > > autoLink {
> > > addr: /domain/subdomain/queue1
> > > dir: in
> > > connection: broker1
> > > }
> > > + the dir: out
> > >
> > > looking at the trace,
> > >
> > > Wed Apr  5 09:51:17 2017 AGENT (debug) Add
> > > entity: AddressEntity(distribution=balanced,identity=address/0,
> > > name=address/0, prefix=/domain/subdomain/queue1,
> > > type=org.apache.qpid.dispatch.router.config.address, waypoint=True)
> > > Wed Apr  5 09:51:17 2017 ROUTER_CORE (trace) Core action
> > > 'manage_create'
> > > …
> > > Wed Apr  5 09:51:17 2017 AGENT (debug) Add
> > > entity: AutoLinkEntity(addr=/domain/subdomain/queue1,
> > > connection=broker1, dir=in, identity=autoLink/0, name=autoLink/0,
> > > type=org.apache.qpid.dispatch.router.config.autoLink)
> > > Wed Apr  5 09:51:17 2017 ROUTER_CORE (trace) Core action
> > > 'manage_create'
> > > Wed Apr  5 09:51:17 2017 AGENT (debug) Add
> > > entity: AutoLinkEntity(addr=/domain/subdomain/queue1, connec...
> > > ...
> > > Wed Apr  5 09:51:17 2017 ROUTER_CORE (info) Auto Link Activated
> > > 'autoLink/0' on connection broker1
> > > Wed Apr  5 09:51:17 2017 ROUTER_CORE (info) Auto Link Activated
> > > 'autoLink/1' on connection broker1
> > >
> > > I see the connection established at the broker level, I do not see
> > > any sessions on

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

Or is do we add a concept of globalAddressDomains at the level of the
vhost?
And have something similar to the qpid broker.

Again the need is to address amqp destination like
amqp://ip:5672/domain/subdomain/dest
amqp://ip:5672/domain2/subdomain2/dest

Thx


On Wed, 5 Apr 2017 at 11:48, Olivier Mallassi <olivier.malla...@gmail.com>
wrote:

> Sorry Ganesh about this, my qdstat was in 0.5.0 :/
>
> I have retried the antoine's test with the following configuration
>
> address {
> prefix: /domain/subdomain/queue1
> waypoint: yes
> }
> connector {
> name: broker1
> role: route-container
> host: localhost
> port: 5672
> saslMechanisms: ANONYMOUS
> }
> autoLink {
> addr: /domain/subdomain/queue1
> dir: in
> connection: broker1
> }
> + the dir: out
>
> looking at the trace,
>
> Wed Apr  5 09:51:17 2017 AGENT (debug) Add entity: 
> *AddressEntity(distribution=balanced,identity=address/0,
> name=address/0, prefix=/domain/subdomain/queue*1,
> type=org.apache.qpid.dispatch.router.config.address, waypoint=True)
>
> Wed Apr  5 09:51:17 2017 ROUTER_CORE (trace) Core action 'manage_create'
>
> …
>
> Wed Apr  5 09:51:17 2017 AGENT (debug) Add entity:
> *AutoLinkEntity(addr=/domain/subdomain/queue1*, connection=broker1,
> dir=in, identity=autoLink/0, name=autoLink/0,
> type=org.apache.qpid.dispatch.router.config.autoLink)
>
> Wed Apr  5 09:51:17 2017 ROUTER_CORE (trace) Core action 'manage_create'
>
> Wed Apr  5 09:51:17 2017 AGENT (debug) Add entity:
> *AutoLinkEntity(addr=/domain/subdomain/queue1*, connec...
>
> ...
>
> Wed Apr  5 09:51:17 2017 ROUTER_CORE (info) *Auto Link Activated
> 'autoLink/0' on connection broker1*
>
> Wed Apr  5 09:51:17 2017 ROUTER_CORE (info) *Auto Link Activated
> 'autoLink/1' on connection broker1*
>
>
> I see the connection established at the broker level, I do not see any
> sessions on it and thus, cannot publish messages. Actually, I got an
> amqp:not-found while trying to send messages
>
>  (trace) [1]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
> [*condition=:"amqp:not-found",
> description="Could not find destination for source
> 'Source{address=domain/subdomain/queue1*
> ,durable=none,expiryPolicy=link-detach,dynamic=false}'"]]
>
>
> The first "/" disappeared (confirmed at qdmanage).
>
>
> I also tried the opposite which is to create the qdrouterd config w/o the
> first "/" (e.g. domain/subdomain...) but then, it looks like the jms
> clients need the first "/" (and get stcuk, waiting for...)
>
> @attach(18)
> [name="qpid-jms:sender:ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1:/domain/subdomain/queue1",
> handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40)
> [address="ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1", durable=0,
> expiry-policy=:"session-end", timeout=0, dynamic=false,
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> :"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
> [address="*/domain/subdomain/queue1*", durable=0,
> expiry-policy=:"session-end", timeout=0, dynamic=false,
> capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
> initial-delivery-count=0,
> desired-capabilities=@PN_SYMBOL[:"DELAYED_DELIVERY"]]
>
> Wed Apr  5 11:25:20 2017 ROUTER_CORE (trace) Core action
> 'link_first_attach'
>
> Wed Apr  5 11:25:20 2017 SERVER (trace) [5]:1 -> @attach(18)
> [name="qpid-jms:sender:ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1:
> */domain/subdomain/queue1*", handle=0, role=true, snd-settle-mode=2,
> rcv-settle-mode=0, source=@source(40)
> [address="ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1", durable=0,
> timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
> :"amqp:rejected:list", :"amqp:released:list", :"amqp:modified:list"]],
> target=@target(41) [address="/domain/subdomain/queue1", durable=0,
> timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]],
> initial-delivery-count=0]
>
>
> I also tried adding two "/" (e.g. //domain/subdomain) but in that case the
> "domain" disappear from the destination name (in qdmanage).
>
> Do I have to use the vhost (the example being using the FQDN)? Can we work
> on a patch to not remove the first "/" if specified in the configuration?
>
>
> Thanks for your help on this.
>
>
> Regards.
>
>
>
> On Fri, Mar 31, 2017 at 3:27 AM, Olivier Mallassi <
> olivier.malla...@gmail.com> wrote:
>

Re: Accessing queues with '/' in name in Rest API [qpid java broker 6.0.4]

[Olivier Mallassi]

Indeed (hostname in the Open frame)
by changing my connection url to ...5672?amqp.vhost=domain2, it works.

thx a lot for your support.

olivier.

On Wed, Apr 5, 2017 at 11:56 AM, Rob Godfrey <rob.j.godf...@gmail.com>
wrote:

> Hi Olivier,
>
> are you connecting to the broker directly or via a dispatch router?
>
> If you are connecting to the broker directly then which virtual host you
> are connecting to will depend on the values the client you used put in the
> "host" field of the open frame.  The assignment of a connection to a
> virtual host happens at "open" time (before you start to use the address of
> any particular queue).  One virtual host in the broker is specified as the
> "default" and this is the vhost used if the client does not populate the
> host field of open at all.  I'm guessing that what you are seeing is that
> the client is not populating host, and so both your connections are being
> made to the "default" virtual host.
>
> -- Rob
>
> On 5 April 2017 at 11:14, Olivier Mallassi <olivier.malla...@gmail.com>
> wrote:
>
> > Hi Rob,
> >
> > quickly test it on the 0.7.0-snapshot and it works like a charm (did not
> > check the patch on 6.0.x) on the default virtualhost from a JMS client.
> > cannot make it work from python (simpleSender.py) but I have to dig into
> > this.
> >
> > one more question on this yet. I tried the following:
> > § create a globalAddressDomain [/domain/subdomain] on the default
> > virtualhost. All queues are addressable through
> > amqp://..:5672/domain/subdomain/queue
> > § create another virtualhost called domain2 and create a
> > globalAddressDomain [/domain2/subdomain] (via POST
> > http:/...8080/api/latest/virtualhost/domain2/domain2). in that case,
> > cannot
> > find the right url pattern to address the queue (It reminds me good old
> > stuff from Apache httpd).
> > While trying to send messages on amqp://..:5672/domain2/
> subdomain/queue2,
> > got an amqp:not-found.
> >
> >
>
>
> > Any tips on this?
> >
> > Regards.
> >
> >
> > On Mon, Apr 3, 2017 at 12:02 PM, Rob Godfrey <rob.j.godf...@gmail.com>
> > wrote:
> >
> > > Apologies, there does indeed seem to be a bug here - I've raised
> > QPID-7732
> > > and fixed on trunk (and also attached a patch for 6.0.x).
> > >
> > > -- Rob
> > >
> > > On 31 March 2017 at 15:47, Antoine Chevin <antoine.che...@gmail.com>
> > > wrote:
> > >
> > > > Hello Rob,
> > > >
> > > > Olivier and I re-checked the global address domain feature and it
> seems
> > > it
> > > > does not resolve the global addresses correctly.
> > > > When I create the queue 'queueA' on the broker and I set the
> > > > globalAddressDomains to '/domain/subdomain', and then I register a
> > > listener
> > > > with JMS for the queue '/domain/subdomain/queueA' I get an
> > > > 'amqp-not-found'.
> > > > Is this expected?
> > > >
> > > > When I told you it worked, I think I had a zombie queue
> > > > '/domain/subdomain/queueA' from my previous attempt to use '/' in
> queue
> > > > names that made it "work" :-(.
> > > >
> > > > Thank you,
> > > > Regards,
> > > > Antoine
> > > >
> > > > -Original Message-
> > > > From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
> > > > Sent: jeudi 2 mars 2017 16:07
> > > > To: users@qpid.apache.org
> > > > Subject: Re: Accessing queues with '/' in name in Rest API [qpid java
> > > > broker 6.0.4]
> > > >
> > > > On 2 March 2017 at 15:11, Antoine Chevin <antoine.che...@gmail.com>
> > > wrote:
> > > >
> > > > > Thank you Rob for the very detailed answer.
> > > > > I saw in the code
> > > > > (org.apache.qpid.server.protocol.v1_0.Session_1_0#
> > remoteLinkCreation)t
> > > > > hat the exchange lookup is skipped if the address starts with a
> '/'.
> > > > > I intend to use a '/' in the beginning because I don't want the
> > > > > exchange lookup.
> > > > > Do you think it is a good approach?
> > > > >
> > > > >
> > > > So the intent here is that addresses that start with "/" are
> considered
> > > to
> > > > be "global" addresses as previously described, ad

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

Sorry Ganesh about this, my qdstat was in 0.5.0 :/

I have retried the antoine's test with the following configuration

address {
prefix: /domain/subdomain/queue1
waypoint: yes
}
connector {
name: broker1
role: route-container
host: localhost
port: 5672
saslMechanisms: ANONYMOUS
}
autoLink {
addr: /domain/subdomain/queue1
dir: in
connection: broker1
}
+ the dir: out

looking at the trace,

Wed Apr  5 09:51:17 2017 AGENT (debug) Add entity:
*AddressEntity(distribution=balanced,identity=address/0,
name=address/0, prefix=/domain/subdomain/queue*1,
type=org.apache.qpid.dispatch.router.config.address, waypoint=True)

Wed Apr  5 09:51:17 2017 ROUTER_CORE (trace) Core action 'manage_create'

…

Wed Apr  5 09:51:17 2017 AGENT (debug) Add entity:
*AutoLinkEntity(addr=/domain/subdomain/queue1*, connection=broker1, dir=in,
identity=autoLink/0, name=autoLink/0,
type=org.apache.qpid.dispatch.router.config.autoLink)

Wed Apr  5 09:51:17 2017 ROUTER_CORE (trace) Core action 'manage_create'

Wed Apr  5 09:51:17 2017 AGENT (debug) Add entity:
*AutoLinkEntity(addr=/domain/subdomain/queue1*, connec...

...

Wed Apr  5 09:51:17 2017 ROUTER_CORE (info) *Auto Link Activated
'autoLink/0' on connection broker1*

Wed Apr  5 09:51:17 2017 ROUTER_CORE (info) *Auto Link Activated
'autoLink/1' on connection broker1*


I see the connection established at the broker level, I do not see any
sessions on it and thus, cannot publish messages. Actually, I got an
amqp:not-found while trying to send messages

 (trace) [1]:0 <- @detach(22) [handle=0, closed=true, error=@error(29)
[*condition=:"amqp:not-found",
description="Could not find destination for source
'Source{address=domain/subdomain/queue1*
,durable=none,expiryPolicy=link-detach,dynamic=false}'"]]


The first "/" disappeared (confirmed at qdmanage).


I also tried the opposite which is to create the qdrouterd config w/o the
first "/" (e.g. domain/subdomain...) but then, it looks like the jms
clients need the first "/" (and get stcuk, waiting for...)

@attach(18)
[name="qpid-jms:sender:ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1:/domain/subdomain/queue1",
handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0,
source=@source(40)
[address="ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1", durable=0,
expiry-policy=:"session-end", timeout=0, dynamic=false,
outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
:"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
[address="*/domain/subdomain/queue1*", durable=0,
expiry-policy=:"session-end", timeout=0, dynamic=false,
capabilities=@PN_SYMBOL[:queue]], incomplete-unsettled=false,
initial-delivery-count=0,
desired-capabilities=@PN_SYMBOL[:"DELAYED_DELIVERY"]]

Wed Apr  5 11:25:20 2017 ROUTER_CORE (trace) Core action 'link_first_attach'

Wed Apr  5 11:25:20 2017 SERVER (trace) [5]:1 -> @attach(18)
[name="qpid-jms:sender:ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1:
*/domain/subdomain/queue1*", handle=0, role=true, snd-settle-mode=2,
rcv-settle-mode=0, source=@source(40)
[address="ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1", durable=0,
timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
:"amqp:rejected:list", :"amqp:released:list", :"amqp:modified:list"]],
target=@target(41) [address="/domain/subdomain/queue1", durable=0,
timeout=0, dynamic=false, capabilities=@PN_SYMBOL[:queue]],
initial-delivery-count=0]


I also tried adding two "/" (e.g. //domain/subdomain) but in that case the
"domain" disappear from the destination name (in qdmanage).

Do I have to use the vhost (the example being using the FQDN)? Can we work
on a patch to not remove the first "/" if specified in the configuration?


Thanks for your help on this.


Regards.



On Fri, Mar 31, 2017 at 3:27 AM, Olivier Mallassi <
olivier.malla...@gmail.com> wrote:

> Hi Ganesh
>
> here it is https://issues.apache.org/jira/browse/DISPATCH-734
> I will try to do more tests.
>
> Thx.
>
> On Thu, Mar 30, 2017 at 4:10 PM, Ganesh Murthy <gmur...@redhat.com> wrote:
>
>>
>>
>> - Original Message -
>> > From: "Olivier Mallassi" <olivier.malla...@gmail.com>
>> > To: users@qpid.apache.org
>> > Cc: "Alan Conway" <acon...@redhat.com>
>> > Sent: Wednesday, March 29, 2017 3:30:48 PM
>> > Subject: Re: Configuring addresses starting with '/' on qpid-dispatch
>> router 0.7.0
>> >
>> > To complement and certainly explain the need, We would like urls like
>> > amqp://ip:port/domain/subdomain1/queueA or
>> > amqp://ip:port/domain/subdomain2/queueB
>> >  + use routing capabilities

Re: Accessing queues with '/' in name in Rest API [qpid java broker 6.0.4]

[Olivier Mallassi]

 an address X it
> > > first looks to see if there is an exchange X, then if there is a queue
> > > X, then if X contains a / it looks to see if the part before the / is
> > > an exchange name, and if so it sends to that exchange with the part
> > > after the / being used as the routing key.
> > >
> > > When the Java Broker receives a request to consume from an address X
> > > it first looks to see if there is a Queue X, then if there is an
> > > Exchange X (in which case it creates a temporary queue and binds with
> > > an empty binding key), and then if X contains a / and the part before
> > > the X is an exchange name it will create a temporary queue and bind
> > > that to the exchange with the binding key being the part of X after the
> > /.
> > >
> > > Note the asymmetry on send and consume that on send it first looks for
> > > an exchange and on consume it first looks for a queue.
> > >
> > > (There are a few more rules for the globalAddressDomains and for
> > > system addresses like $management, but the above is the general rule).
> > >
> > > -- Rob
> > >
> > >
> > > > Thank you,
> > > > Regards,
> > > > Antoine
> > > >
> > > > On 1 March 2017 at 20:25, Olivier Mallassi
> > > > <olivier.malla...@gmail.com>
> > > > wrote:
> > > >
> > > > > Rob, all
> > > > >
> > > > > Thank you rob for this. Could you please share more details
> > > > > regarding not using the "/"?
> > > > >
> > > > >
> > > > So there are a couple of reasons why I think not using a / makes
> sense:
> > > >
> > > > 1) Because of exactly the REST / encoding issue that you ran into -
> > > > using characters that often need escaping can cause a lot of issues
> > > > in config files, parameters etc...  depending upon where the queue
> > > > name might be used you may end up encoding that / one, two or even
> > > > more times... this gets messy fast
> > > >
> > > > 2) Because in AMQP addressing we've been imaging the / as a
> > > > separator when using some sort of topological address scheme for
> > > > addressing in federated networks... for instance you might have a
> > > > queue for orders in you dongle department of your widget division of
> > > > your company foo.com... and you might expose that address as
> > > > //foo.com/widget/dongle/orders  whereas someone connected directly
> > > > to
> > > the
> > > broker would just see the queue as "orders"
> > > > (though they could also address it by its full "global" name).  The
> > > > Java Broker already makes some allowance for this with the notion of
> > > > "globalAddressDomains" which you can set on the virtual host.  For
> > > > any domain  in the list of defined globalAddressDomains, the
> > > > virtualhost will accept messages sent /M as if it were sent to
> > > > M (and the same with consuming).
> > > >
> > > > Also note that for the Java Broker an address of the form  > > > name>/ can be used to send / receive via AMQP 0-x
> > > > exchange/routing-key semantics.
> > > >
> > > > Hope this helps,
> > > > Rob
> > > >
> > > >
> > > > > On our side we are using amqp 1.0 that, AFAIU, promotes the
> "complex"
> > > > > addressing plans
> > > > > The benefit for us would be
> > > > > - alignements between our http and amqp naming conventions. It is
> > > > > a nice to have but can help lisibility
> > > > > - use "URL" to route messages. Like the samples with the
> > > > > linkroutepattern
> > > > >
> > > > > Not sure these are good ideas btw. Any feedback is welcomed
> > > > >
> > > > > Regards
> > > > >
> > > > > On Wed, 1 Mar 2017 at 18:16, Rob Godfrey <rob.j.godf...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > In general I'd advise against using the '/' character in queue
> > > > > > names if possible... however if you must, then you need double
> > > > > > encode the name, so "a/b" would become "a%252Fb"
> > > > > >
> > > > > > Hope this helps,
> > > > > > Rob
> > > > > >
> > > > > > On 1 March 2017 at 17:31, Antoine Chevin
> > > > > > <antoine.che...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I created a queue with a '/' in the name. How can I access it
> > > > > > > in the
> > > > > rest
> > > > > > > api?
> > > > > > > I tried to encode the '/' with %2F but I still get a 422 "too
> > > > > > > many
> > > > > > entries
> > > > > > > in path for REST servlet queue."
> > > > > > > Can you please help?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Antoine
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

Hi Ganesh

here it is https://issues.apache.org/jira/browse/DISPATCH-734
I will try to do more tests.

Thx.

On Thu, Mar 30, 2017 at 4:10 PM, Ganesh Murthy <gmur...@redhat.com> wrote:

>
>
> - Original Message -----
> > From: "Olivier Mallassi" <olivier.malla...@gmail.com>
> > To: users@qpid.apache.org
> > Cc: "Alan Conway" <acon...@redhat.com>
> > Sent: Wednesday, March 29, 2017 3:30:48 PM
> > Subject: Re: Configuring addresses starting with '/' on qpid-dispatch
> router 0.7.0
> >
> > To complement and certainly explain the need, We would like urls like
> > amqp://ip:port/domain/subdomain1/queueA or
> > amqp://ip:port/domain/subdomain2/queueB
> >  + use routing capabilities to route queueA, queueB on different brokers
> or
> > even queueA to brokers and queueB to another dispatch-router (e.g. for
> > external integration)
> >
> > I did some really quick and basic tests using the dispatch-router.
> > § qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> > addr=/domain/subdomain/queueA dir=in connection=broker3
> > § sending / receiving messaging using the simple_recv/send.py scripts.
> >
> > It appears that the messages are well published / consumed. sounds
> correct
> > to you?
> >
> > yet (and this is not really important), the qdstat displays weird labels
> >
> > mobile  queue.first0   0  0   00
> > 0 00
> >
> >   local   temp.2ndwYNc5ZaHaD2O   1  0   0
> > 00 00
> >
> >   unknown: s  ubdomain/queueA1  0   200
> > 200  0 00
> >
> >   unknown: s  ubdomain/queueA0  0   0
> > 00 00
> >
> > version used: dispatch-router 0.7.0
> >
> The above qdstat output does look weird. Can you please enter a JIRA
> detailing the steps we can use to reproduce this this problem?
> Thanks.
> >
> > On Wed, Mar 29, 2017 at 12:15 PM, Rob Godfrey <rob.j.godf...@gmail.com>
> > wrote:
> >
> > > On 29 March 2017 at 11:48, Ted Ross <tr...@redhat.com> wrote:
> > >
> > > >
> > > >
> > > > On 03/08/2017 02:33 PM, Alan Conway wrote:
> > > >
> > > >> On Fri, 2017-03-03 at 09:58 +, Antoine Chevin wrote:
> > > >>
> > > >>> Hello,
> > > >>>
> > > >>> Do you have an idea on the below behavior?
> > > >>>
> > > >>
> > > >> This is related to early drafts of the AMQP addressing
> specification,
> > > >> but those are out of date now and the specification is still not
> > > >> released.
> > > >>
> > > >> Given that, I think this behavior is probably not helpful - dispatch
> > > >> should accept address exactly as provided by the user and do no
> > > >> modification. I'm not 100% sure if that would cause any internal
> > > >> problems for the router, if not we should raise an issue.
> > > >>
> > > >> Ted do you have any thoughts?
> > > >>
> > > >
> > > > Dispatch normalizes addresses to make sure that various "equivalent"
> > > forms
> > > > are hashed to the same entry in the address table.
> > > >
> > > > As Alan pointed out, we use a URL-like address format per early
> drafts of
> > > > the addressing specification.  As such, the leading slash is removed
> from
> > > > the normalized address.
> > > >
> > > >
> > > What are the normalization rules, and why is dispatch assuming that
> > > removing a leading slash is correct (since in this case it is not - the
> > > Java Broker does its own normalization - and if you want you can query
> it
> > > and find out what prefixes it considers equivalent)?
> > >
> > > -- Rob
> > >
> > >
> > > >
> > > >
> > > >>
> > > >>> Thank you,
> > > >>> Regards,
> > > >>> Antoine
> > > >>>
> > > >>> -Original Message-
> > > >>> From: Antoine Chevin [mailto:antoine.che...@gmail.com]
> > > >>> Sent: jeudi 2 mars 2017 10:43
> > > >>> To: users@qpid.apache.org
> > > >>> Subject: Configuring addresses starting with '/' on qpid-dispatch
> > > >>> router
> > > >>> 0.7.0
> > > >>>
> > > >>> Hello,
> > > >>>
> > > >>> I tried to configure addresses starting with a '/' but using
> qdstat I
> > > >>> see
> > > >>> that this '/' is removed. Is it expected?
> > > >>> I noticed the same behavior with autolinks.
> > > >>>
> > > >>> Thank you,
> > > >>> Regards,
> > > >>> Antoine
> > > >>>
> > > >>
> > > >>
> > > > 
> -
> > > > 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: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

To complement and certainly explain the need, We would like urls like
amqp://ip:port/domain/subdomain1/queueA or
amqp://ip:port/domain/subdomain2/queueB
 + use routing capabilities to route queueA, queueB on different brokers or
even queueA to brokers and queueB to another dispatch-router (e.g. for
external integration)

I did some really quick and basic tests using the dispatch-router.
§ qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
addr=/domain/subdomain/queueA dir=in connection=broker3
§ sending / receiving messaging using the simple_recv/send.py scripts.

It appears that the messages are well published / consumed. sounds correct
to you?

yet (and this is not really important), the qdstat displays weird labels

mobile  queue.first0   0  0   00
0 00

  local   temp.2ndwYNc5ZaHaD2O   1  0   0
00 00

  unknown: s  ubdomain/queueA1  0   200
200  0 00

  unknown: s  ubdomain/queueA0  0   0
00 00

version used: dispatch-router 0.7.0


On Wed, Mar 29, 2017 at 12:15 PM, Rob Godfrey 
wrote:

> On 29 March 2017 at 11:48, Ted Ross  wrote:
>
> >
> >
> > On 03/08/2017 02:33 PM, Alan Conway wrote:
> >
> >> On Fri, 2017-03-03 at 09:58 +, Antoine Chevin wrote:
> >>
> >>> Hello,
> >>>
> >>> Do you have an idea on the below behavior?
> >>>
> >>
> >> This is related to early drafts of the AMQP addressing specification,
> >> but those are out of date now and the specification is still not
> >> released.
> >>
> >> Given that, I think this behavior is probably not helpful - dispatch
> >> should accept address exactly as provided by the user and do no
> >> modification. I'm not 100% sure if that would cause any internal
> >> problems for the router, if not we should raise an issue.
> >>
> >> Ted do you have any thoughts?
> >>
> >
> > Dispatch normalizes addresses to make sure that various "equivalent"
> forms
> > are hashed to the same entry in the address table.
> >
> > As Alan pointed out, we use a URL-like address format per early drafts of
> > the addressing specification.  As such, the leading slash is removed from
> > the normalized address.
> >
> >
> What are the normalization rules, and why is dispatch assuming that
> removing a leading slash is correct (since in this case it is not - the
> Java Broker does its own normalization - and if you want you can query it
> and find out what prefixes it considers equivalent)?
>
> -- Rob
>
>
> >
> >
> >>
> >>> Thank you,
> >>> Regards,
> >>> Antoine
> >>>
> >>> -Original Message-
> >>> From: Antoine Chevin [mailto:antoine.che...@gmail.com]
> >>> Sent: jeudi 2 mars 2017 10:43
> >>> To: users@qpid.apache.org
> >>> Subject: Configuring addresses starting with '/' on qpid-dispatch
> >>> router
> >>> 0.7.0
> >>>
> >>> Hello,
> >>>
> >>> I tried to configure addresses starting with a '/' but using qdstat I
> >>> see
> >>> that this '/' is removed. Is it expected?
> >>> I noticed the same behavior with autolinks.
> >>>
> >>> Thank you,
> >>> Regards,
> >>> Antoine
> >>>
> >>
> >>
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>

Re: Accessing queues with '/' in name in Rest API [qpid java broker 6.0.4]

[Olivier Mallassi]

Rob, all

Thank you rob for this. Could you please share more details regarding not
using the "/"?

On our side we are using amqp 1.0 that, AFAIU, promotes the "complex"
addressing plans
The benefit for us would be
- alignements between our http and amqp naming conventions. It is a nice to
have but can help lisibility
- use "URL" to route messages. Like the samples with the linkroutepattern

Not sure these are good ideas btw. Any feedback is welcomed

Regards

On Wed, 1 Mar 2017 at 18:16, Rob Godfrey  wrote:

> In general I'd advise against using the '/' character in queue names if
> possible... however if you must, then you need double encode the name, so
> "a/b" would become "a%252Fb"
>
> Hope this helps,
> Rob
>
> On 1 March 2017 at 17:31, Antoine Chevin  wrote:
>
> > Hello,
> >
> > I created a queue with a '/' in the name. How can I access it in the rest
> > api?
> > I tried to encode the '/' with %2F but I still get a 422 "too many
> entries
> > in path for REST servlet queue."
> > Can you please help?
> >
> > Regards,
> > Antoine
> >
>

Re: Qpid proton C++ supports failover url?

[Olivier Mallassi]

We may be able to use load balancer like HAProxy (level 4)
But retry has to be handled; maybe proton-c provide something.

On Friday, 16 September 2016,  wrote:

>
>
> Hello,
>
>
> Does the Proton C++ API support the failover url just like JMS does?
>
> If no, what workarounds could I use?
>
>
> Regards,
>
> Adel
>
>
> Get Outlook for Android
>
>
>

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Olivier Mallassi]

We need to run the tests again but you are right. Looking at the Dispatch
Router config, the links are in and out.
thx.


On Fri, Jul 8, 2016 at 5:47 PM, Ted Ross <tr...@redhat.com> wrote:

>
>
> On 07/08/2016 11:42 AM, Olivier Mallassi wrote:
>
>> Hi Rob
>>
>> We have the following topology:
>>
>> * Publisher -> Dispatcher -> Broker1 or Broker 2 (Java) -> Dispatcher
>> (same
>> instance) -> Consumer
>> * each Broker is configured (before the run)
>> - with an exchange perf.topic (amqp topic)
>> - with a queue  (perf.queue) that has a binding (binding key + header
>> based
>> filtering) to the perf.topic exchange
>>
>> * the Dispatcher is configured with autoLink
>> * The publisher publish in perf.topic (kind of distributed topic)
>> * The consumer consume from perf.queue (distributed queue)
>> * Dispatch version is 0.6.0 and Broker is in version 6.0.0.
>>
>
> I think your autoLink _in_ from perf.topic is spurious.  I suspect that
> there are no consumers on the router consuming from "perf.topic" and
> therefore the listener attached to the temporary queue is never issued
> credit and it accumulates all perf.topic messages.
>
>
>
>> We have the expected behavior : published messages are load-balanced on
>> brokers and consumed as expected.
>>
>> Yet, and we observed the OOM while running the test for a longer time,
>> when
>> the dispatcher connect, it creates a queue with a UUID (more or less)
>> name.
>> that queue is bind to perf.topic with # as a binding key (so every
>> messages
>> sent by the publisher fill up this queue thus the OOM because it is in
>> memory).
>>
>> It looks to be "expected".
>> Is there a way to avoid this? are we missing something?
>>
>> Many thx.
>>
>> oliv/
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 8, 2016 at 5:16 PM, Rob Godfrey <rob.j.godf...@gmail.com>
>> wrote:
>>
>> Hi Adel,
>>>
>>> I'm a bit confused... you say
>>>
>>> As no consumer is connected to this queue, all messages are kept
>>>>
>>> in-memory which causes the OutOfMemory exception in the broker.
>>>
>>> but then also say
>>>
>>> Consumer connected to that queue (Is it the dispatcher?):
>>>> Name: qdlink.OyY41QAJRZ4JGGg
>>>> Mode: MOVE
>>>>
>>>
>>> Does the queue have a consumer or not?
>>>
>>> As to holding on to the messages... the heap dump shows that the message
>>> is
>>> in the queue (which we know) and has not been evicted by flow to disk
>>> (we'd
>>> need to work out why)...
>>>
>>> On average what size are the messages you are sending?  Do you see
>>> messages
>>> flow through this topic at all?
>>>
>>> As to the "weird" queue name - what is happening is that we are creating
>>> an
>>> internal temporary queue when you subscribe to an exchange object in the
>>> broker... for that we use a UUID as the queue name.
>>>
>>> -- Rob
>>>
>>> On 8 July 2016 at 15:48, Adel Boutros <adelbout...@live.com> wrote:
>>>
>>> I forgot to add that when I execute a qdmanage command to delete the
>>>> "connector" to the broker, the weird queue disappears.
>>>>
>>>> Adel
>>>>
>>>> Date: Fri, 8 Jul 2016 07:45:49 -0700
>>>>> From: adelbout...@live.com
>>>>> To: users@qpid.apache.org
>>>>> Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to
>>>>>
>>>> qpid dispatcher
>>>>
>>>>>
>>>>> Fixing bad formatting on Nabbledue to Hotmail:
>>>>>
>>>>> Hello,
>>>>>
>>>>> We are doing some performance tests with a Qpid Java Broker connected
>>>>>
>>>> to
>>>
>>>> a
>>>>
>>>>> Qpid dispatcher.
>>>>> We have noticed that after some time, the broker dies with an
>>>>>
>>>> OutOfMemory
>>>
>>>> exception and java heap is dumped.
>>>>> After analyzing the heap dump and checking the broker, we have noticed
>>>>>
>>>> 2
>>>
>>>> weird behaviors:
>>>>>
>>>>> 1) A queue is created on the broker with a weird Name bound on our
>>>>>
>>>> topic
>&

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Olivier Mallassi]

Ted,

yes. this is as you describe
the queue that fills up is the "UUID name" queue (created by the Dispatch
Router ).

On Fri, Jul 8, 2016 at 5:42 PM, Olivier Mallassi <olivier.malla...@gmail.com
> wrote:

> Hi Rob
>
> We have the following topology:
>
> * Publisher -> Dispatcher -> Broker1 or Broker 2 (Java) -> Dispatcher
> (same instance) -> Consumer
> * each Broker is configured (before the run)
> - with an exchange perf.topic (amqp topic)
> - with a queue  (perf.queue) that has a binding (binding key + header
> based filtering) to the perf.topic exchange
>
> * the Dispatcher is configured with autoLink
> * The publisher publish in perf.topic (kind of distributed topic)
> * The consumer consume from perf.queue (distributed queue)
> * Dispatch version is 0.6.0 and Broker is in version 6.0.0.
>
> We have the expected behavior : published messages are load-balanced on
> brokers and consumed as expected.
>
> Yet, and we observed the OOM while running the test for a longer time,
> when the dispatcher connect, it creates a queue with a UUID (more or less)
> name. that queue is bind to perf.topic with # as a binding key (so every
> messages sent by the publisher fill up this queue thus the OOM because it
> is in memory).
>
> It looks to be "expected".
> Is there a way to avoid this? are we missing something?
>
> Many thx.
>
> oliv/
>
>
>
>
>
>
> On Fri, Jul 8, 2016 at 5:16 PM, Rob Godfrey <rob.j.godf...@gmail.com>
> wrote:
>
>> Hi Adel,
>>
>> I'm a bit confused... you say
>>
>> > As no consumer is connected to this queue, all messages are kept
>> in-memory which causes the OutOfMemory exception in the broker.
>>
>> but then also say
>>
>> > Consumer connected to that queue (Is it the dispatcher?):
>> > Name: qdlink.OyY41QAJRZ4JGGg
>> > Mode: MOVE
>>
>> Does the queue have a consumer or not?
>>
>> As to holding on to the messages... the heap dump shows that the message
>> is
>> in the queue (which we know) and has not been evicted by flow to disk
>> (we'd
>> need to work out why)...
>>
>> On average what size are the messages you are sending?  Do you see
>> messages
>> flow through this topic at all?
>>
>> As to the "weird" queue name - what is happening is that we are creating
>> an
>> internal temporary queue when you subscribe to an exchange object in the
>> broker... for that we use a UUID as the queue name.
>>
>> -- Rob
>>
>> On 8 July 2016 at 15:48, Adel Boutros <adelbout...@live.com> wrote:
>>
>> > I forgot to add that when I execute a qdmanage command to delete the
>> > "connector" to the broker, the weird queue disappears.
>> >
>> > Adel
>> >
>> > > Date: Fri, 8 Jul 2016 07:45:49 -0700
>> > > From: adelbout...@live.com
>> > > To: users@qpid.apache.org
>> > > Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to
>> > qpid dispatcher
>> > >
>> > > Fixing bad formatting on Nabbledue to Hotmail:
>> > >
>> > > Hello,
>> > >
>> > > We are doing some performance tests with a Qpid Java Broker connected
>> to
>> > a
>> > > Qpid dispatcher.
>> > > We have noticed that after some time, the broker dies with an
>> OutOfMemory
>> > > exception and java heap is dumped.
>> > > After analyzing the heap dump and checking the broker, we have
>> noticed 2
>> > > weird behaviors:
>> > >
>> > > 1) A queue is created on the broker with a weird Name bound on our
>> topic
>> > > (perf.topic) with a binding key "#". It will receive all messages.
>> > > This queue seems to be created only when the dispatcher is present
>> and is
>> > > configured.
>> > > As no consumer is connected to this queue, all messages are kept
>> > in-memory
>> > > which causes the OutOfMemory exception in the broker.
>> > >
>> > > Weird Queue definition
>> > > Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
>> > > Type: standard
>> > > State: ACTIVE
>> > > Durable: false
>> > > Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
>> > > Persist Messages: NEVER
>> > > Inbound: 0 msg/s (0.00 B/s)
>> > > Outbound: 0 msg/s (0.00 B/s)
>> > > Size: 2374 msgs (0.00 B)
>> > > Pre-fetched: 0 msgs (0.00 B)
>> > > Oldest Message Age:

Re: client certificate and client hostname check

[Olivier Mallassi]

Hi all,

Thank you for your answers. this is very helpful!
I was indeed hesitating between IP/hostname in the certificate (knowing it
could be a mess to manage) and filtering on the IP. I think the latter
option looks good enough.

@Rob, Thank you for your proposal. I do not have strong needs/commitments
on this for now so :). Thank you for routing me on the ACLs.
@Gordon, I was reading this
http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html
and indeed, it looks like the last version of the dispatcher may support
these filtering features (using policy and policyRuleSet)

Again, thx.

Olivier.




On Thu, Jun 9, 2016 at 10:40 PM, Rob Godfrey 
wrote:

> On 9 June 2016 at 22:19, Gordon Sim  wrote:
>
> > On 09/06/16 21:00, Rob Godfrey wrote:
> >
> >> Hi Olivier,
> >>
> >> Speaking for the Java Broker, there is currently no mechanism to tie the
> >> TLS client certificate to the host name or IP address corresponding to
> the
> >> origin of the TCP/IP connection (I'd imagine this is also the case for
> >> Dispatcher but I'll let someone more knowledgable on that codebase step
> in
> >> there).  Similarly to the C++ broker as described in the document
> Chester
> >> provided, when using the SSL Client Certificates on a connection we
> simply
> >> verify that the certificate has been signed by a trusted source, and
> then
> >> (if the External Auth Provider is being used) take the identity from the
> >> certificate itself.
> >>
> >> It's certainly shouldn't be a big job to add the ability to verify that
> >> the
> >> certificate provided by the client in the TLS negotiation has a DN or
> SAN
> >> which corresponds to the IP address or reverse-looked-up DNS name of the
> >> machine initiating the connection.  Obviously in your use case as
> >> described
> >> below this would be validating that the connection from a Dispatcher
> >> instance is coming from the expected machine for the Dispatcher... it
> >> won't
> >> be verifying anything about the client which connects to the Dispatcher.
> >>
> >> Would you be interested in me implementing something to add this
> >> functionality to the Java Broker?
> >>
> >
> > My suggestion would be to restrict the authenticated client identity to
> > connect only from given IP addresses. That way your certificates just
> > identify the client (and are not tied to a given host or ip address) and
> > you can update the whitelisted/blacklisted ips for a given client
> identity
> > more easily.
> >
> > The router can do this now, I believe.
> >
> >
> >
> Yes - that will also work if you have a reasonably static set of users /
> hosts connecting and want to have the configuration at the server...  The
> Java Broker also supports ACL rules that limit access to a given virtual
> host for a given user (or group) to a set of IP Addresses or DNS host
> names.  The difference (I don't know if this is the property that Olivier
> needs) is that the TLS certificate mechanism doesn't need the broker to be
> reconfigured in order for a new client / host to be added...  that is taken
> care of solely by the generation of a certificate which is is signed by the
> trusted authority.
>
> -- Rob
>
>
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>

client certificate and client hostname check

[Olivier Mallassi]

All,

The whole idea is
(1) to build the following chain : clients (Java/c++) <-> dispatcher(s) <->
java qpid brokers.
(2) with two ways SSL between all the components

test are ongoing but I was wondering if there is a way to configure the
dispatchers and the brokers to check (or not) the client hostname (while
checking the client certificate)?
if activated, does it use the CN for hostname?

Thx for your help.

Cheers.

Olivier.

Re: [c++] Proposal for application function injection.

[Olivier Mallassi]

hello all

I have to say I am far from being fluent in c++ but one thing we really
like about proton is that it has no dependency and can be used in legacy
code

I do not know if the boost::function option will drive a dependency to
boost but this is maybe something to take into account.

Again, I may be wrong

Cheers

Olivier

On Monday, 21 March 2016, Alan Conway  wrote:

> On Thu, 2016-03-17 at 17:19 -0400, Andrew Stitcher wrote:
> > On Thu, 2016-03-17 at 17:09 -0400, Alan Conway wrote:
> > >
> > > The proton::container is single threaded, once you call run() you
> > > can't
> > > interact with it from other threads.
> > >
> > > I'd like to propose a "function injection" interface. I think the
> > > analogous thing could be done for all the languages. The Go binding
> > > already has this mechanism.
> > >
> > > The idea is to provide a thread safe call that injects a simple
> > > "callable" object with no parameters and no return value.
> > >
> > > In  C++11 this is easy to do:
> > >
> > > class container {
> > > void inject(std::function)
> > > }
> > >
> > > Semantics: calling inject() will queue the injected function to be
> > > called as soon as is reasonable in the run() thread.
> > This is definitely the interface I was thinking of.
> >
> > I'm not clear exactly how the context carrying through the event
> > queue
> > works though to be honest.
>
> So there are two issues:
>
> 1. which event loop are you injecting into. I think once we have
> connections in more than one thread we'll need to inject into a
> specific connection, not just into the container. Something like
>
> myconnection.driver().inject(...)
>
> In a single-threaded container, each connection could return the same
> (container level) driver but in a multi-threaded container each
> connection would potentially have its own driver. In fact we could
> provide a driver() on each endpoint and walk up the containment
> hierarchy, so link::driver() would return its connection's driver etc.
>
> 2. how to supply context to the function being called. That can be done
> by binding arguments, so for example:
>
>   sender s =
> myconnection.driver().inject(std::bind(connection::open_sender,
> myconnection, "foo", ...)
>   s.driver().inject(std::bind(sender::send, s, mymsg...)
>
> After only a few lines of this you want something like Gordon's
> BlockingConnection interface, I would see this as the enabler for
> implementing that.
>
> > > In C++03 we can support the functionality in a clunky way that is
> > > not
> > > very efficient or easy to use, but works:
> > It's actually exactly as efficient in principle as it does the same
> > thing without the decent syntax!
>
> Not unless we re-implement boost::function or std::function. We need a
> copyable, non-template type for functors that we can store where it can
> be picked up by another thread, which is hard. There is an easy, ugly
> way using pointers to base classes with virtual functions but it
> involves allocations for every inject, refcounting or some other
> tricksy memory mnagement.
>
> >
> > My objection to this is that I don't think this precise proposal
> > would
> > allow you to use a boost::function<> and tbh that's the only way I
> > would do this sort of thing in '03.
>
> I think we have 3 options and we need to decide which/how many to
> offer:
>
> - std::function
> - boost::function
> - clunky base-class pointers
>
> Less is better for us :) I think you're right that boost::function
> might be a better second choice than base class pointers since that's
> very widely available.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org 
> For additional commands, e-mail: users-h...@qpid.apache.org 
>
>

Re: [C++ broker] How to create filters and queues from the client

[Olivier Mallassi]

Hi

I do not know about the JS API but

1/ AFAIK, AMQP 1.0 does not define anything regarding queue creation and
assume queues already exist on the broker side.
2/ with qpid cpp,  you could be able to create the "filtered queue " with

 qpid-config add exchange topic subjects

qpid-config add queue mysubscription
--argumentqpid.filter="\"amqp.correlation_id\"='abc'
AND color='blue' AND weight > 2500"

  qpid-config bind subjects mysubscription mysubject



HTH.

oliv/

On Thu, Mar 10, 2016 at 5:03 PM, Morgan Lindqvist <
morgan.lindqv...@ericsson.com> wrote:

> Hi All,
>
> I was previously using AMQP 0.9.1 (RabbitMQ) and the client library amqplib
> for Node JS. With these components it was easy to give the client the
> possibility to create the queue and the bindingKey and connect it to an
> topic-exchange.
>
> I now would like a client to create a queue and a filter and connect it to
> an existing node using QPIDD and the Node JS library amqp10.
>
> So far I have not discovered any way to do this from the client.
>
> I have also been looking for documentation for how to create and describe a
> filter (so that it works like a bindingKey for 0.9.1). I have however not
> been successful. Or have I misunderstood how filters can be used?
>
> Assistance to make me move forward is highly appreciated.
>
> Best Regards,
> Morgan
>
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/C-broker-How-to-create-filters-and-queues-from-the-client-tp7639889.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: General Question: Network Load Balanacing?

[Olivier Mallassi]

Hi Paul

Regarding your question.it looks like federation in one option, dispatcher
is the other one.

With dispatcher, you can create distributed topology  like

publishers --> dispatcher --> array of brokers (they do not know each
other) --> dispatcher --> consumers.

The broker can be java or c++.

In that case, the publisher / consumers use a single logical destination.
which is physically spread accross the broker (if configured that way).

I think you can find some details on the ML (e.g.
http://qpid.2158936.n2.nabble.com/how-to-scale-out-qpid-td7625000.html#a7625009
)

HTH.


oliv/





On Thu, Feb 25, 2016 at 9:22 PM, Steve Huston  wrote:

> Hi Paul,
>
> I work with a set of customers that set this kind of thing up as a set of
> meshed brokers with federation links that both load balances and acts as a
> mechanism of high availability.
>
> -Steve Huston
>
> > -Original Message-
> > From: Flores, Paul A. [mailto:paul.a.flo...@saic.com]
> > Sent: Thursday, February 25, 2016 3:13 PM
> > To: users@qpid.apache.org
> > Subject: General Question: Network Load Balanacing?
> >
> > At a client site evaluating aspects of QPID for adoption for its use in
> a mission
> > critical application.
> >
> >
> >
> > This is one question / area I was asked to elicit information regarding
> current
> > capabilities, plans and alternatives.
> >
> >
> >
> > Has anyone looked at either the distributed broker functionality and /
> or the
> > dispatcher in this context?  If so can you please share your insights.
> >
> >
> >
> > Is there anything specific in this area someone can point me towards?
> >
> >
> >
> > Thanks your thoughts, insights, comments and inputs are welcomed.
> >
> >
> >
> > Paul
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

[Dispatch] reload config

[Olivier Mallassi]

Hello all

Is there a way to reload the conf file of Dispatch or do I need to reboot
it?

Regards.

oliv/

Re: [C++/Java Broker] [Transactions]

[Olivier Mallassi]

Hi all,


sorry.

I have tried to summarize all this content in this table
https://docs.google.com/spreadsheets/d/1JilNwbBSftHxPZymJoaSeSA1uxpp9ZwXZyzDM9q6LQA/edit?usp=sharing

Hope that helps

oliv/

PS: thx for the precisions on the link between on
session/transaction/process.



On Tue, Jan 5, 2016 at 12:54 PM, Gordon Sim  wrote:

> On 01/05/2016 11:42 AM, Robbie Gemmell wrote:
>
>> On 4 January 2016 at 19:59, Gordon Sim  wrote:
>>
>>> On 12/30/2015 06:37 PM, aconway wrote:
>>>
 I believe dispatch *could* support at least some of the AMQP 1.0 TX and
 DTX modes even with message routing, we just haven't gotten there yet.

>>>
>>>
>>> For local transactions, any transfer or disposition related to the
>>> transaction needs to be routed to the same process, over the same
>>> connection[1], as that to which the transaction controller link is
>>> routed.
>>>
>>> [1] If the multi-ssns-per-txn capability is not supported by the process
>>> in
>>> question, the same session would have to be used. If the
>>> multi-txns-per-ssn
>>> capability was not supported then you would need a unique session for
>>> every
>>> distinct transaction.
>>>
>>>
>> To clarify that last bit, I asume you mean every currently active
>> transaction?
>>
>
> Yes, once the transaction is completed the session would be free to be
> associated with another one.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [C++ Broker][HA Queue Replication]

[Olivier Mallassi]

Again, thank you for all these details.

In my case, I think I would prefer the federation option because I am fine
with the fact the broker can "queue" and store messages backlog. Yet, let
me think about this ;)

Your remark regarding the unreliable side is interesting. In fact, I was
thinking about using distributed (not federated) brokers,  behind a couple
of dispatch routers (and implement distributed queues) but I may not even
need brokers. maybe a "dispatch router" acting as a relay would work
perfectly!


On Wed, Dec 30, 2015 at 7:09 PM, aconway <acon...@redhat.com> wrote:

> On Fri, 2015-12-18 at 09:24 +0100, Olivier Mallassi wrote:
> > Hi all
> >
> > Gordon, thx.
> >
> > Regarding your last question "What are you aiming to achieve with the
> > federation? Is it scaling beyond the capacity of a single broker?" I
> > would
> > say, "at term, yes"
> >
> > In fact, I have two main use-cases.
> > 1/ the first one must be reliable. In that case, persistence and
> > clustering
> > should be used. But it must also be able to scale. Federation gives
> > me a
> > way to scale the publisher side by sending events in any brokers
> > (round-robin load balancing) and behind the scene, the messages will
> > end up
> > in the right queue on the right broker (based on the bindings /
> > routing
> > key).
> > It should be ok if routing keys are filtering events enough.
>
> You should be able to do this with dispatch to a HA cluster also. I'm
> very interested in making sure dispatch works well in a HA environment
> so let me know of any issues you come across.
>
> >
> > 2/ the second one is unreliable but "low latency", must scale beyond
> > broker
> > capacity (almost sure), and HA. So you can loose message but the
> > distribution chain must stay up and continue broadcasting incoming
> > events.
> > In that case, I do not want clustering (cause I do not want to pay
> > the
> > price of replication), but the dispatch router can help me because it
> > gives
> > me distributed queues. (I agree it will help me with security/proxies
> > etc...)
> >
> > What are your thoughts on this?
>
> > On my side, clearly, the NFR (& figures) need to be clarified and
> > more perf
> > tests will be done.
> > I am yet figuring out how to play with the 4 dimensions (persistence,
> > clustering, federation, dispatch router) to build these channels, the
> > simplest way possible.
> >
>
> Dispatch: can help with scale, it does connection concentration and
> (very limited) buffering so you can funnel large numbers of clients to
> a single broker. The limited buffering can be considered a feature:
> clients trying to send to an overloaded broker via dispatch will
> experience flow-control back-pressure and slow down their sending till
> the broker acks messages.
>
> Federation: a lot like dispatch in that you can set up flexible
> mapping/routing rules. The big difference is a federated broker *does*
> take responsibility for messages and can be a persistent and/or HA
> "buffer" on the way to the final destination.
>
> The dispatch/federation trade off is: do you want your clients to be
> forced to slow down when the "real" back-end is overloaded and wait
> till it can handle more data, or do you want long "fire and forget"
> buffers so clients can drop messages and move on even if the system is
> busy? Buffers can help you get better throughput over short load spikes
> but sustained overload will cause growing queues, growing latency and
> generally bigger trouble before your clients start to back off.
>
>
> For your summary my "gut reaction" would be to try dispatch to a
> cluster or group of clusters initially for the reliable part. There is
> a "distributed queue" test in the dispatch codebase that shows how you
> can implement a "single queue" (from the sender and subscriber
> perspective) as a set of queues on separate brokers - each of which
> could be a cluster. I would add federation only if you have a need for
> the kind of buffering I mention above, otherwise the dispatch topology
> and horizontally adding clusters should cover a lot of scaling issues.
>
> For the unreliable side I would guess you could use dispatch alone - if
> it is ok to lose messages if nobody is listening, then that is exactly
> the default behavior for dispatch.
>
> Also the advantage of a dispatch backbone is you can change your choice
> of broker without any effect on the clients. Only the broker
> configuration would be different.
>
>

[C++/Java Broker] [Transactions]

[Olivier Mallassi]

Hi all

again, my apologies for all these questions.

I am trying to clarify my understanding around transactions support within
qpid and here is my current understanding (based on documentation & JIRA).
I have to say I did not test anything yet.

My use cases all go into the same pattern : (1) writes into a DB &
publishes messages or (2) consumes messages and updates a DB, all of this
being "atomic" (e.g. if the DB writings fail, messages are not sent
etc...), with Java & C++ clients and I am figuring out if I can rely on XA
/ DTX or if I need to find another implementation.

Here is my current understanding, any comments are welcomed.

AMQP 0.10AMQP 1.0Deployment typeC++ API JMS APIC++ API JMS APIHA Java
brokeractive/Passive
cluster of Java brokerslocal transactionokokokokdistributed / XA
transactionsokokokokFederated + HA C++ Brokers- Federated Exchanges +
clustering of CPP Brokers
- persistence (no message loss)local transactionok (
https://issues.apache.org/jira/browse/QPID-3384)

but looks redundant with https://issues.apache.org/jira/browse/QPID-4328

*not sure the backup are asynchronously updated*?ok (
https://issues.apache.org/jira/browse/QPID-4710)?distributed / XA
transactionsko (based on
https://issues.apache.org/jira/browse/QPID-4328)???Dispatch
Router- local tx will be supported (
https://issues.apache.org/jira/browse/DISPATCH-195)
- distributed tx may be supported


So as you can see, I am not clear about distributed transactions support
(AMQP 0.10 or 1.0). Can you help ?


Cheers.

oliv/

Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID while using JMS Selector

[Olivier Mallassi]

it looks like this is exactly what I was looking for! I will try it (after
christmas)

Looking at the qpid.filter definition, it looks like I can use a rich
grammar (AND, OR, LIKE?). Is this define somewhere?

Regarding the --argument, I was looking at the python source (
https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/py/qpid-config)
but cannot find anything.

anyway. Thank you very much.

oliv/

On Tue, Dec 22, 2015 at 7:23 PM, Gordon Sim  wrote:

> On 12/22/2015 06:13 PM, Gordon Sim wrote:
>
> (You could use a headers exchange instead of the topic exchange and do
>> some of the selection logic there, but the only reason to do so I think
>> would be if it were more efficient than the selector. I don't know
>> whether it would be as it hasn't been optimised much. The topic exchange
>> is the most efficient means of selection, so if the subject is
>> sufficient as a first level, that might work well).
>>
>
> And if you didn't want to do any selection at the exchange, and just rely
> on the selector, you could bind the queue to a 'fanout' exchange.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID while using JMS Selector

[Olivier Mallassi]

hum. regarding the auto-delete, looks like this is my fault.

I changed my JMS code to explicitly use a temp queue

TemporaryQueue tmpQueue = session.createTemporaryQueue();
messageConsumer = session.createConsumer(tmpQueue, "msg selector")


and then the queues are created as auto delete
temp_rcv_qpid-jms:temp-queue-creator:ID::48e3b12c-a7f8-42cf-b499-168ddda7546a:1:1
 auto-del

do not need to use the QueuePolicy



On Tue, Dec 22, 2015 at 10:50 AM, Olivier Mallassi <
olivier.malla...@gmail.com> wrote:

> - I am using session.createConsumer(myTopic, "messageSelector") so AFAIK,
> it is not durable subscription. I was also reading
> http://qpid.2158936.n2.nabble.com/Autodelete-queues-not-deleted-td7633221.html
> and the QueuePolicy. Not sure how it maps to the jms destination name
> (maybe the jms.queueprefix) but maybe that can help
>
> - indeed JMS 2.0 defined shared subscription. Anyway, maybe during that
> time I need to rely on AMQP 0.10 bindings (within the broker) to have
> queues on which consumers can compete.
>
>
>
> On Tue, Dec 22, 2015 at 10:39 AM, Gordon Sim <g...@redhat.com> wrote:
>
>> On 12/22/2015 09:22 AM, Olivier Mallassi wrote:
>>
>>> by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
>>> creates a queue with an uniqueID for each receiver (e.g.
>>>
>>> MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
>>>
>>
>> Actually that queue is created on the broker side. The name comes from
>> the container id and link name.
>>
>> - is there a way to auto-delete this "queue" when the consumer JVM shut
>>> down?
>>>
>>
>> It should be auto-deleted by default, unless the client requests
>> otherwise. Is it a durable subscription on the topic that you created?
>>
>> - is there a way to share this "queue" between multiple consumers so that
>>> they can compete each other?
>>>
>>
>> At the AMQP protocol level, all receiving links that  request a 'shared'
>> capability on the link and use the same link name (from the same topic
>> obviously) will share the subscription (i.e. the messages from that
>> subscription will be distributed between them). (This is not a standard
>> capability).
>>
>> I'm not sure if the JMS client will allow you to set the capabilities
>> though (Robbie?). At some point the JMS client will support JMS 2.0 which
>> includes the notion of shared subscriptions and as part of that a standard
>> approach at the protocol level will hopefully emerge.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>

Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID while using JMS Selector

[Olivier Mallassi]

- I am using session.createConsumer(myTopic, "messageSelector") so AFAIK,
it is not durable subscription. I was also reading
http://qpid.2158936.n2.nabble.com/Autodelete-queues-not-deleted-td7633221.html
and the QueuePolicy. Not sure how it maps to the jms destination name
(maybe the jms.queueprefix) but maybe that can help

- indeed JMS 2.0 defined shared subscription. Anyway, maybe during that
time I need to rely on AMQP 0.10 bindings (within the broker) to have
queues on which consumers can compete.



On Tue, Dec 22, 2015 at 10:39 AM, Gordon Sim <g...@redhat.com> wrote:

> On 12/22/2015 09:22 AM, Olivier Mallassi wrote:
>
>> by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
>> creates a queue with an uniqueID for each receiver (e.g.
>>
>> MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
>>
>
> Actually that queue is created on the broker side. The name comes from the
> container id and link name.
>
> - is there a way to auto-delete this "queue" when the consumer JVM shut
>> down?
>>
>
> It should be auto-deleted by default, unless the client requests
> otherwise. Is it a durable subscription on the topic that you created?
>
> - is there a way to share this "queue" between multiple consumers so that
>> they can compete each other?
>>
>
> At the AMQP protocol level, all receiving links that  request a 'shared'
> capability on the link and use the same link name (from the same topic
> obviously) will share the subscription (i.e. the messages from that
> subscription will be distributed between them). (This is not a standard
> capability).
>
> I'm not sure if the JMS client will allow you to set the capabilities
> though (Robbie?). At some point the JMS client will support JMS 2.0 which
> includes the notion of shared subscriptions and as part of that a standard
> approach at the protocol level will hopefully emerge.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID while using JMS Selector

[Olivier Mallassi]

by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
creates a queue with an uniqueID for each receiver (e.g.
MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)

- is there a way to auto-delete this "queue" when the consumer JVM shut
down?
- is there a way to share this "queue" between multiple consumers so that
they can compete each other?

Cheers.

On Mon, Dec 21, 2015 at 9:51 PM, Olivier Mallassi <
olivier.malla...@gmail.com> wrote:

> thanks.
>
> On Mon, Dec 21, 2015 at 9:45 PM, Gordon Sim <g...@redhat.com> wrote:
>
>> On 12/21/2015 08:43 PM, Olivier Mallassi wrote:
>>
>>> Are the filters executed  on the broker?
>>>
>>
>> Yes
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>

Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID while using JMS Selector

[Olivier Mallassi]

not sure I got your question but I would answer : competing consumers

In fact, in AMQP 1.0,
- if I connect my consumer on a destination which is a topic, with
JMSSelector, this works but I get a subscription that I cannot share
between multiple consumers (so no load balancing). maybe it can work if I
do not use JMS but proton-j or an API that gives me access to the link
definition.
- if I connect to a queue, my JMSSelector is applied on the queue (which
fills up with the messages that do not match the selector)

on the other hand, if I do this in AMQP 0.10, this is almost straigh
forward: publish to headers exchange, bind your queues (config), then you
have competing consumers on each queues.

So, as I would like to continue using JMS as the API, I guess I was trying
to rely more on the broker capabilities to filter / route my messages. not
sure this is the good approach, btw.




On Tue, Dec 22, 2015 at 5:57 PM, Gordon Sim <g...@redhat.com> wrote:

> On 12/22/2015 04:09 PM, Olivier Mallassi wrote:
>
>> (my apologies for bothering you with all these questions...)
>>
>
> Not at all!
>
> It looks like JMSType (subject) or JMSCorrelationID are not used (or that
>> my binding is false).
>>
>
> The subject should match if you use that as the binding key when creating
> the binding (instead of ''). The headers exchange won't look at the
> correlation-id though I'm afraid.
>
> Is there a particular reason you need/want a headers exchange as opposed
> to just using a selector on a topic subscription (to e.g. a fanout
> exchange)?
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID while using JMS Selector

[Olivier Mallassi]

thanks.

On Mon, Dec 21, 2015 at 9:45 PM, Gordon Sim <g...@redhat.com> wrote:

> On 12/21/2015 08:43 PM, Olivier Mallassi wrote:
>
>> Are the filters executed  on the broker?
>>
>
> Yes
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID while using JMS Selector

[Olivier Mallassi]

Looks like my understanding of addressing in AMQP 1.0 is not that
good...and that I am still struggling to forget the AMQP 0.10 concepts. But
your comment helped me.

In fact my address was specifying a queue. so the behavior is as expected.

Are the filters executed  on the broker?

On Mon, Dec 21, 2015 at 6:19 PM, Gordon Sim <g...@redhat.com> wrote:

> On 12/21/2015 05:02 PM, Olivier Mallassi wrote:
>
>> Based on this discussion, the JMSCorrelation ID  should be ok in the next
>> release: https://issues.apache.org/jira/browse/QPID-6714
>>
>
> Yes, that is correct.
>
> Why do messages stay in the queue server side? related to
>> https://issues.apache.org/jira/browse/QPID-5030?
>>
>
> What address are you consuming from when you specify the filter? In qpidd
> terms, if you specify the filter when the node is an exchange (or topic)
> then the selector  should be applied to select which messages get enqueued.
> If the node is a queue however then the selector only controls the messages
> actually consumed from the queue.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [C++ Broker][HA Queue Replication]

[Olivier Mallassi]

Hi all

Gordon, thx.

Regarding your last question "What are you aiming to achieve with the
federation? Is it scaling beyond the capacity of a single broker?" I would
say, "at term, yes"

In fact, I have two main use-cases.
1/ the first one must be reliable. In that case, persistence and clustering
should be used. But it must also be able to scale. Federation gives me a
way to scale the publisher side by sending events in any brokers
(round-robin load balancing) and behind the scene, the messages will end up
in the right queue on the right broker (based on the bindings / routing
key).
It should be ok if routing keys are filtering events enough.

2/ the second one is unreliable but "low latency", must scale beyond broker
capacity (almost sure), and HA. So you can loose message but the
distribution chain must stay up and continue broadcasting incoming events.
In that case, I do not want clustering (cause I do not want to pay the
price of replication), but the dispatch router can help me because it gives
me distributed queues. (I agree it will help me with security/proxies
etc...)

What are your thoughts on this?

On my side, clearly, the NFR (& figures) need to be clarified and more perf
tests will be done.
I am yet figuring out how to play with the 4 dimensions (persistence,
clustering, federation, dispatch router) to build these channels, the
simplest way possible.

Cheers.






On Wed, Dec 16, 2015 at 1:02 PM, Gordon Sim <g...@redhat.com> wrote:

> On 12/15/2015 04:40 PM, Olivier Mallassi wrote:
>
>> Hi all
>>
>> I am still digging into the qpid technologies in order to better
>> understand
>> how all the pieces can be tied together.
>> switching to the C++ broker implementation, I am trying to understand how
>> HA cluster and federation can work together and your feedback would be
>> appreciated.
>>
>> AFAIU, if I mix Federation and HA clustering I can end up with a
>> deployment
>> like this one (hope the formatting will stay)
>>
>>
>> publisher (C++/Java) --> |  Federated Broker.1 Active + Passive |
>>   |  Federated Broker.2 Active + Passive | -->
>> Consumer
>>   |  Federated Broker.3 Active + Passive |
>>
>> So for a 3 nodes federated broker, I have 6 processes + 3 vip (or
>> something
>> to promote the passive as a new primary in case of failure). which is
>> fine.
>>
>> I was then trying to reduce the number of processes using the HA Queue
>> replication (which looks like a subpart of the HA module and just
>> replicate
>> the queue - and not the complete broker)
>> With this, I am able to have
>>
>> publisher (C++/Java) --> |  Federated Broker.1 Active
>>  |
>>   |  Federated Broker.2 Active
>>  | --> Consumer
>>   |  Federated Broker.3 Active  + Consumer queue
>> replica |
>>
>>
>> then comes a couple of questions:
>> - are the queues asynchronously replicated (or sync replicated if the
>> consumers has not yet consumed the message as explained in the doc)?
>>
>
> The publisher will not get an acknowledgement for any message they publish
> until either it has been acknowledged by the passive backups or by the
> consuming client.
>
> - Is there a way to properly handle fail-over in that case? because from
>> the doc, and I can understand this, it does not look to be a good idea to
>> write into the queue replica? but I do not see a way to promote it as
>> master.
>>
>
> You should never write to- or consume from- a backup. There is a tool
> (qpid-ha) for manually promoting one of the backups to master. The usual
> (recommended) practice is to use something like pacemaker to control this.
> There is probably some example script or doc around this but I can't locate
> it at the moment. (Alan?)
>
> - Is this even the good approach?
>>
>
> What are you aiming to achieve with the federation? Is it scaling beyond
> the capacity of a single broker?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Router][Java Broker] connect failed between Router & Java Broker

[Olivier Mallassi]

Rob,

Sorry for the late answer.
-  I have build the 6.1.0-SNAPSHOT of the Java Broker (with your fix)
- it fixes the issue. so thank you.

When starting the router, I see the following logs

[0x25a7420]:  <- SASL
[0x25a7420]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[0x25a7420]:0 <- @sasl-outcome(68) [code=0]
[0x25a7420]:  <- AMQP
[0x25a7420]:0 <- @open(16)
[container-id="0b7af9a1-1911-49f3-91df-97caa5f40705", max-frame-size=65536,
channel-max=255, idle-time-out=0, properties={:product="qpid",
:version="6.1.0-SNAPSHOT", :"qpid.build"="Unversioned directory",
:"qpid.instance_name"="Broker"}]
[0x25a7420]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15,
outgoing-window=2147483647]
[0x25a7420]:1 -> @begin(17) [next-outgoing-id=0, incoming-window=15,
outgoing-window=2147483647]
[0x25a7420]:0 -> @attach(18) [name="payments", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
timeout=0, dynamic=false], target=@target(41) [address="payments",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x25a7420]:1 -> @attach(18) [name="payments", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="payments", durable=0, timeout=0, dynamic=false],
target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0]
[0x7f1e6400d890]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2048, outgoing-window=2048]
[0x7f1e6400d890]:1 <- @begin(17) [remote-channel=1, next-outgoing-id=0,
incoming-window=2048, outgoing-window=2048]
[0x7f1e6400d890]:0 <- @attach(18) [name="payments", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
timeout=0, dynamic=false], target=@target(41) [address="payments",
durable=0, timeout=0, dynamic=false]]
[0x7f1e6400d890]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2048,
next-outgoing-id=0, outgoing-window=2048, handle=0, delivery-count=0,
link-credit=2, echo=false]
[0x7f1e6400d890]:1 <- @attach(18) [name="payments", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="payments", durable=0, timeout=0, dynamic=false,
distribution-mode=:copy], target=@target(41) [durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x25a7420]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2048, outgoing-window=2048]
[0x25a7420]:1 <- @begin(17) [remote-channel=1, next-outgoing-id=0,
incoming-window=2048, outgoing-window=2048]
[0x25a7420]:0 <- @attach(18) [name="payments", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
timeout=0, dynamic=false], target=@target(41) [address="payments",
durable=0, timeout=0, dynamic=false]]
[0x25a7420]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2048,
next-outgoing-id=0, outgoing-window=2048, handle=0, delivery-count=0,
link-credit=2, echo=false]
[0x25a7420]:1 <- *@attach(18) *[name="payments", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="payments", durable=0, timeout=0, dynamic=false,
distribution-mode=:copy], target=@target(41) [durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]

- I am then able to  JMS Publisher --> Router --> Java Broker 1 & 2 (v
6.1.0-SNAPSHOT) --> Router --> JMS Consumer w/ simple addressing plan like
amqp://mybroker/payments (which is an amqp.topic exchange). I still have a
mystery because the router create a temporary queue bind to # (but the
queue depth continue inceasing).

So while publishing events, on the router side
[0x7fd66000d7a0]:0 -> @*transfer*(20) [handle=0, delivery-id=49,
delivery-tag=b"e\x00\x00\x00\x00\x00\x00\x00", message-format=0,
settled=false, more=false] (232)
"\x00Sp\xc0\x02\x01A\x00Sr\xd1\x00\x00\x00G\x00\x00\x00\x04\xa3\x0ex-opt-qd.trace\xd0\x00\x00\x00\x10\x00\x00\x00\x01\xa1\x0a0/router.A\xa3\x10x-opt-qd.ingress\xa1\x0a0/router.A\x00Ss\xc0]\x0a\xa1-ID:POMALLASSI-63527-1449819382571-0:1:1:1-100@
\xa1\x08payments\xa1\x0epayments.error@\xa1\x03abc@@@\x83\x00\x00\x01Q\x8f\xf83\xa8\x00St\xc1\x1b\x04\xa1\x06weightq\x00\x00\x0a(\xa1\x05color\xa1\x04blue\x00Sw\xa1\x0bHello
World"
[0x7fd66000d7a0]:0 <- @*disposition*(21) [role=true, first=49, last=49,
settled=true, *state=@accepted*(36) []]

Do you want me to add this as a comment in the JIRA?

thank you.

oliv/


On Thu, Dec 10, 2015 at 10:55 AM, Rob Godfrey <rob.j.godf...@gmail.com>
wrote:

> Hi Olivier,
>
> On 9 December 2015 at 10:06, Robbie Gemmell <robbie.gemm...@gmail.com>
> wrote:
>
> > On 8 December 2015 at 21:21, Olivier Mallassi
> > <olivier.malla...@gmail.com> wr

Re: [Router][Java Broker] connect failed between Router & Java Broker

[Olivier Mallassi]

(39) [delivery-failed=false,
undeliverable-here=true]]



Tue Dec  8 11:06:53 2015 SERVER (debug) Accepting incoming connection from
192.168.56.102:59820 to 192.168.56.103:2
(/home/omallassi/qpid-dispatch-0.5/src/server.c:231)
Tue Dec  8 11:06:53 2015 MESSAGE (trace) Received Message{to='payments'
body='\a1'} on link
qpid-jms:sender:ID:POMALLASSI-59817-1449570029482-0:1:1:1:payments
(/home/omallassi/qpid-dispatch-0.5/src/message.c:721)


So it looks like the router received the message with the address payments
(which is my topic name I am publishing to)

Yet, on the broker side, no FRM / RAW message. so the broker does not
receive any messages from the router.


my router config defined as follow
router & connector info etc..
waypoint {
address: payments
out-phase: 1
in-phase: 0
connector: broker1
}

fixedAddress {
prefix: payment
phase: 0
fanout: single
bias: spread
}


for sure my target address is not good but can someone help me
understanding this. When my JMS client publish, can it publish to a topic
and this is transform in an address like amqp://brokerip/payments? Do I
need to publish to address that respect the _topo/area/...I have to say
this part is quite blur...




@Keith and regarding the connection between the router and the Java broker, I
quickly tested the same config on version 6.0.0 w/o success.

*on broker side*
2015-12-08 09:59:55,586 DEBUG [IO-/192.168.56.103:52422] (FRM) -
SEND[/192.168.56.103:52422|0] : SaslOutcome{code=ok}
2015-12-08 09:59:57,589 INFO  [IO-/192.168.56.103:52422] *(q.m.c.idle_close)
- [con:34(/192.168.56.103:52422 <http://192.168.56.103:52422>)] CON-1003 :
Closed due to inactivity*
*2015-12-08 09:59:57,590 DEBUG [IO-/192.168.56.103:52422
<http://192.168.56.103:52422>] (FRM) - RECV[/192.168.56.103:52422|-1] :
Underlying connection closed*
2015-12-08 10:00:02,598 DEBUG [IO-/192.168.56.103:52423] (FRM) -
SEND[/192.168.56.103:52423|0] :
SaslMechanisms{saslServerMechanisms=[ANONYMOUS]}
2015-12-08 10:00:02,599 DEBUG [IO-/192.168.56.103:52423] (FRM) -
RECV[/192.168.56.103:52423|0] :
SaslInit{mechanism=ANONYMOUS,initialResponse=anonymous}

*on router side *

Connected to 192.168.56.103:10002
[0x7ff65400a530]:  -> SASL
[0x7ff65400a530]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
initial-response=b"anonymous"]
[0x7ff65400a530]:  -> AMQP
[0x7ff65400a530]:0 -> @open(16) [container-id="qpid.dispatch.router.A",
max-frame-size=65536, channel-max=32767,
offered-capabilities=:"ANONYMOUS-RELAY",
properties={:product="qpid-dispatch-router", :version="0.5"}]
[0x7ff65400a530]:  <- SASL
[0x7ff65400a530]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[0x7ff65400a530]:0 <- @sasl-outcome(68) [code=0]
[0x7ff65400a530]:  <- AMQP
[0x7ff65400a530]:0 -> @close(24) [error=@error(29)
*[condition=:"amqp:connection:framing-error",
description="connection aborted"]]*
[0x7ff65400a530]:  <- EOS
[0x7ff65400a530]:  -> EOS



*and then on the router log *

Tue Dec  8 10:00:02 2015 SERVER (trace) Connecting to 192.168.56.103:10002
(/home/omallassi/qpid-dispatch-0.5/src/server.c:816)
Tue Dec  8 10:00:04 2015 SERVER (trace) Connection to 192.168.56.103:10002
failed (/home/omallassi/qpid-dispatch-0.5/src/server.c:438)

I should have mis-configured something.
I did not investigate more than that (I need to focus on the dispatch /
broker integration) but let me know if you want me to try some tests





On Tue, Dec 8, 2015 at 12:15 AM, Keith W <keith.w...@gmail.com> wrote:

> Hi Olivier
>
> For the Java Broker, you are correct that it defaults to a
> PlainPasswordProvider assigned to the AMQP port, so it will fail unless you
> have the client authenticate.  If you didn't change this already, then I
> would have expected your first experiment (AMQP client direct to Java
> Broker) to fail.   To set up the anonymous provider, you need to create the
> anonymous authentication provider AND assign it to the AMQP port.  You can
> do these both through the UI.  You'll then need to restart the Broker to
> have the changes picked up.
>
> To turn on logging for the AMQP 1.0 in the Java Broker, you need to enable
> the loggers called simply FRM (the frame level logging)  and RAW (for the
> bytes).  You don't mention which version of the Java Broker you use.  If
> you are on 0.32 and below, you need to add these loggers to the
> etc/log4j.xml file at level DEBUG.   If you are testing the 6.0.0 release
> candidate you can enabled logging of FRM and RAW through the Web Management
> Console.  Just add a new Log Inclusion Rule for both at level DEBUG.
>
> Let us know what you see.
>
> Keith.
>
> On 7 December 2015 at 19:54, Ted Ross <tr...@redhat.com> wrote:
>
> > You shoul

Re: [JMS] [AMQP 1.0] link definition and guarantee delivery

[Olivier Mallassi]

@Robbie, thank you for clarification

On Mon, Dec 7, 2015 at 1:07 PM, Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:

> On 4 December 2015 at 19:09, Olivier Mallassi
> <olivier.malla...@gmail.com> wrote:
> > Hello all
> >
> > I am beginning to figure out how the JMS & AMQP specs. yet I am facing a
> > copule of questions:
> >
> > *1/ competing & non competing consumers: *
> >
> > using amqp 0.10 and Jms destinations, I was able to publish my events on
> > amq.topic/x.y.z
> > and then to consume these events from different subscription queues A &
> B,
> > (using the binding x.*.z).
> >
> > on A, I can have competing consumers. on B also but no competition
> between
> > A & B.
> >
> > I am able to do the same with AMQP 1.0 by
> > - pre configuring my queues on the broker (and then the consumers listen
> to
> > it)
> > - publishing in a queue / topic (no difference)
> > topic.myTopic=amq.topic/x.y.z or topic.myTopic=amq.topic and
> > myJMSMessage.setJMSType("xyz"). both solution works since setJMSType is
> > mapped to amqp subject.
> >
> > Is this the right way?
>
> It is certainly one way yes.
>
> I'm assuming that you are using the Java broker here based on your
> mails. The core 1.0 spec only really deals with 'nodes' (e.g
> queues/topics) that have an explicit 'address', which you attach
> producers/consumers to (or utilise in the message 'to' field). The
> java broker is actually interpreting the first address as an exchange
> name + routing key because it has a "/" in it. When publishing to an
> exchange using an address without the "/" it is then similarly looking
> at the message Subject field and interpreting that as a routing key.
> Both of these behaviours are essentially a way of mapping AMQP 1.0
> onto the older AMQP 0-x concepts of exchange+routing-key (which dont
> exist in 1.0) the broker already supported thanks to implementing
> those protocols. I think the C++ broker supports the latter of those
> behaviours as well.
>
>
> > Is there a way to dynamically create the queues (on consumer side) (with
> > the equivalent of create:always)?
> >
>
> The core AMQP 1.0 protocol has no built in facility to explicitly
> create name queues etc (except 'dynamic' nodes, e.g temporary queues,
> anmed by the broker) in the way that prior AMQP 0-x protocols did, as
> it instead concentrated on getting messages from A to B rather than
> defining an explicit broker model that must be implemented. There is
> an effort at the OASIS AMQP TC to define a layered AMQP Management
> specification that uses AMQP messaging to support implementing such
> management operations (and many others).
>
> When recieveing from an exchange address, I believe the java broker
> will make an implicit temporary queue to funnel messages to the
> consumer. That process might (im not sure) support similar trickery
> with "/" in the address to create that queue using a specific binding.
> An alternative to that might be adding a selector on JMSType if the
> messages all have a Subject set. Someone more familiar with the 1.0
> support in the Java broker might be able to add something here.
>
> If you want explicitly named queues with particular bindings, I think
> you will need to create them in advance.
>
> > I observe that I cannot publish as long as there is no binding defined
> (at
> > the broker level). I got javax.jms.JMSException: Unknown error from
> remote
> > peer
> > Is it expected? can I publish into the broker (previously exchange) even
> if
> > no bindings are defined?
> >
>
> I'd guess whats happening here is that the message is being rejected
> (without a specific error) due to the lack of binding, and the client
> is interpreting that as a failure to send and reacting accordingly.
>
> Someone more familiar with the 1.0 support in the Java broker might be
> able to add something here.
>
> >
> > *2/ destination. *
> > Looking at that page, as MRG is based on cpp qpid (
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/3/html-single/Messaging_Programming_Reference/index.html#Apache_Qpid_JNDI_Properties_for_AMQP_Messaging
> )
> > destination. are supported.
> >
> > Looking at the code, (and the JmsInitialContextFactory, it looks like
> only
> > queue. & topic. are supported.
> > Yet, looking at the AmqpProducerBuilder.createEndpoint(), the target
> > address is used, as is (based on the specified JmsDestination) and set
> into
> > the source.
> >
> > same for the Consumer.
> &

[Router][Java Broker] connect failed between Router & Java Broker

[Olivier Mallassi]

Hello everybody,

I am facing an issue while (attempting to connect the router and a java
broker)

- I have a JMS client *successfully* publishing to the Java broker (AMQP
1.0) w/ the following url

env.put("connectionfactory.qpidConnectionfactory", "amqp://
192.168.56.103:1?clientid=test-client=default");


- then I want to "put" a router between and have a simple topology JMS
client -> router -> Java Broker

Based on different links (
http://qpid.2158936.n2.nabble.com/Dispatch-Router-distributed-topics-td7611684.html#a7611710,
http://qpid.2158936.n2.nabble.com/Dispatch-Router-distributed-topics-td7611684.html#a7611710,
https://issues.apache.org/jira/browse/DISPATCH-126 ) I have ended up with
the following qdrouter.conf


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

listener {
addr: 192.168.56.103
port: 2
saslMechanisms: ANONYMOUS
requireSsl: no
authenticatePeer: no
}

connector {
name: broker1
role: on-demand
addr: 192.168.56.103
port: 1
sasl-mechanisms: ANONYMOUS
}

router {
mode: standalone
routerId: router.A
}


waypoint {
address: payments
in-phase: 0
out-phase: 1
connector: broker1
}

waypoint {
address: instruction
in-phase: 0
out-phase: 1
connector: broker1
}

fixed-address {
prefix: instruction
phase: 0
fanout: single
bias: spread
}

fixed-address {
prefix: instruction
phase: 1
fanout: single
bias: closest
}


log {
module: DEFAULT
enable: trace+
source: true
output: /tmp/router.A.log
}


Yet, while starting the qdrouter, I see the different entities creation but
at the end, I got

Mon Dec  7 18:29:51 2015 SERVER (trace) Connecting to 192.168.56.103:1
(/home/omallassi/qpid-dispatch-0.5/src/server.c:816)
Mon Dec  7 18:29:51 2015 SERVER (trace) Connection to 192.168.56.103:1
failed (/home/omallassi/qpid-dispatch-0.5/src/server.c:438)
Mon Dec  7 18:29:56 2015 SERVER (trace) Connecting to 192.168.56.103:1
(/home/omallassi/qpid-dispatch-0.5/src/server.c:816)
Mon Dec  7 18:29:56 2015 SERVER (trace) Connection to 192.168.56.103:1
failed (/home/omallassi/qpid-dispatch-0.5/src/server.c:438)
Mon Dec  7 18:30:01 2015 SERVER (trace) Connecting to 192.168.56.103:1
(/home/omallassi/qpid-dispatch-0.5/src/server.c:816)
Mon Dec  7 18:30:01 2015 SERVER (trace) Connection to 192.168.56.103:1
failed (/home/omallassi/qpid-dispatch-0.5/src/server.c:438)

on the broker side (Log level debug) no logs.


I thought it was because the Java Broker has a default
authenticationProvider to PlainPasswordFile. I configured the Java Broker
w/ anonymous authenticationProvider but got the same error.

Do you have any idea of what's going on? or what kind of test / config I
can do to better understand the problem.

Thanks a lot.

[JMS] [AMQP 1.0] link definition and guarantee delivery

[Olivier Mallassi]

Hello all

I am beginning to figure out how the JMS & AMQP specs. yet I am facing a
copule of questions:

*1/ competing & non competing consumers: *

using amqp 0.10 and Jms destinations, I was able to publish my events on
amq.topic/x.y.z
and then to consume these events from different subscription queues A & B,
(using the binding x.*.z).

on A, I can have competing consumers. on B also but no competition between
A & B.

I am able to do the same with AMQP 1.0 by
- pre configuring my queues on the broker (and then the consumers listen to
it)
- publishing in a queue / topic (no difference)
topic.myTopic=amq.topic/x.y.z or topic.myTopic=amq.topic and
myJMSMessage.setJMSType("xyz"). both solution works since setJMSType is
mapped to amqp subject.

Is this the right way?
Is there a way to dynamically create the queues (on consumer side) (with
the equivalent of create:always)?

I observe that I cannot publish as long as there is no binding defined (at
the broker level). I got javax.jms.JMSException: Unknown error from remote
peer
Is it expected? can I publish into the broker (previously exchange) even if
no bindings are defined?


*2/ destination. *
Looking at that page, as MRG is based on cpp qpid (
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/3/html-single/Messaging_Programming_Reference/index.html#Apache_Qpid_JNDI_Properties_for_AMQP_Messaging)
destination. are supported.

Looking at the code, (and the JmsInitialContextFactory, it looks like only
queue. & topic. are supported.
Yet, looking at the AmqpProducerBuilder.createEndpoint(), the target
address is used, as is (based on the specified JmsDestination) and set into
the source.

same for the Consumer.

so the support for destination. looks doable and would give us
the ability to define (in JMS) something like
destination.myName= "amq.topic/#.news;{node:{capabilities:[shared]},
link:{name: 'news'}}"

or to use amq.match. or benefit from the address schema (
https://github.com/apache/qpid-proton/blob/master/proton-c/src/messaging.xml
)


Am I wrong? Do I miss something?


*3/ guarantee delivery and message persistence. *

AFAIU, if the message is marked JMSDeliveryMode.PERSISTENT, then it is
marked as durable modulo the reliablity of the link/target.

Again, AFAIU, at the broker level, as long as my vhost is declared durable
(derby based for instance), my message will be persisted. so no message
loss in case of restard of the broker.

regarding the link, when a create the end point on the broker, I see the
following log:


2015-12-04 15:10:08,670 DEBUG [IoReceiver - /192.168.56.102:60754] (FRM) -
RECV[/192.168.56.102:60754|1] :
Attach{name=qpid-jms:sender:ID:POMALLASSI-60751-1449239241646-0:1:1:1:amq.topic/x.y.z,handle=0,role=sender,s
*ndSettleMode=unsettled,rcvSettleMode=first,*source=Source{address=ID:POMALLASSI-60751-1449239241646-0:1:1:1,durable=none,expiryPolicy=session-end,timeout=0,dynamic=false,outcomes=[amqp:accepted:list,
amqp:rejected:list]},target=Target{address=amq.topic/x.y.z,durable=none,expiryPolicy=session-end,timeout=0,dynamic=false,capabilities=[queue]},incompleteUnsettled=false,initialDeliveryCount=0}


- Why is my target defined as non durable?
- looking at the settlemode, by default the AMQPProducerBuidler set the
settle-mode à unsettled (and it looks related to AMQPProvider). can I
change this mode using the property amqp.preSettleProducers?
- Is this is only 'properties' that gives me guarantee delivery?


Sorry for that long email and thanks for you help. then will have to
integrate all of this with the router.


Regards.


oliv/

Re: qpid dispatch & transaction

[Olivier Mallassi]

Thanks Ted.

I have found this
https://github.com/apache/qpid-proton/blob/master/docs/markdown/messenger/addressing-and-routing.md
may be useful.

On Thu, Dec 3, 2015 at 9:13 PM, Ted Ross <tr...@redhat.com> wrote:

>
> On 12/03/2015 09:20 AM, Olivier Mallassi wrote:
>
>> gentlemen, thank you for your answers.
>>
>> @Ted: I am currently trying to use the router and so I am moving to AMQP
>> 1.0 (which by itself is a topic). So, I would say yes. Were you thinking
>> about any limitations / recommendations regarding the linkRoutePattern?
>>
>
> No, I think link-routes are what you need to best serve your use case.
>
>
>> @Jack, Ted: I will look at the settlement & disposition knowing I cannot
>> afford to loose a message (Financial Services).
>>
>> The overall idea would be to create that chain:  publisher (Java/qpid-JMS
>> or C++/Qpid Messaging) --> routers --> brokers (prefered option java, if
>> not C++ is fine) --> routers --> consumers (Java / qpid-JMS)
>>
>> For sure this will not be straight forward but it seems doable? no?
>>
>
> Yes, this is doable.  It is one of the intended use cases for Dispatch
> Router.
>
> With regard to the link-protocol/message-settlement:  The router(s) don't
> ever assume ownership of transiting messages.  In other words, the routers
> will not acknowledge or settle messages that pass through them.  That is
> left to the endpoints.  So any messages that are lost due to router failure
> or connection failure will remain in-doubt between the publisher/consumer
> and the broker and will therefore be re-sent once the loss of connectivity
> is fixed.
>
>
>
>> oliv/
>>
>> On Wed, Dec 2, 2015 at 5:18 PM, Ted Ross <tr...@redhat.com> wrote:
>>
>> Dispatch does support the full AMQP link protocol (settlement and
>>> disposition).
>>>
>>> -Ted
>>>
>>>
>>> On 12/02/2015 11:15 AM, Gibson, Jack wrote:
>>>
>>> You could possibly just use settlements and acknowledgements not sure of
>>>> the support with dispatch for that. At least you could manage some level
>>>> of delivery guarantees.
>>>>
>>>> Jack Gibson
>>>> Chief Architect
>>>> Core Payments Platforms/PayPal
>>>>
>>>>
>>>>
>>>> On 12/2/15, 7:22 AM, "Ted Ross" <tr...@redhat.com> wrote:
>>>>
>>>> As Jack correctly pointed out, this is currently a missing feature in
>>>>
>>>>> Dispatch Router.  There is a Jira
>>>>> (https://issues.apache.org/jira/browse/DISPATCH-195) open to track the
>>>>> issue.
>>>>>
>>>>> In your use case, are you using routed links (i.e. with
>>>>> linkRoutePattern
>>>>> in your router configuration)?
>>>>>
>>>>> Also, since your use case involves a database, are you expecting
>>>>> support
>>>>> for XA or distributed transactions?  We plan to add local transactions
>>>>> (client-to-broker, or endpoint-to-endpoint) in the near future but
>>>>> distributed transactions will take longer.
>>>>>
>>>>> -Ted
>>>>>
>>>>> On 12/01/2015 06:52 PM, Olivier Mallassi wrote:
>>>>>
>>>>> hello all
>>>>>>
>>>>>> I was wondering if qpid dispatch was supporting trnasaction. in fact
>>>>>> the
>>>>>> pattern I would need to implement is the following (a classic one)
>>>>>>
>>>>>> Publisher (java/c++)
>>>>>> beginTransaction > insert rdbms > publish msg > commit
>>>>>>
>>>>>> the amqp infra would be dispatch + java qpid broker.
>>>>>>
>>>>>> I assume it works. Can someone confirm please?
>>>>>>
>>>>>> Thx for your help
>>>>>>
>>>>>> olivier.
>>>>>>
>>>>>>
>>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>>
>>>>
>>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>
>>>
>>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: qpid dispatch & transaction

[Olivier Mallassi]

gentlemen, thank you for your answers.

@Ted: I am currently trying to use the router and so I am moving to AMQP
1.0 (which by itself is a topic). So, I would say yes. Were you thinking
about any limitations / recommendations regarding the linkRoutePattern?

@Jack, Ted: I will look at the settlement & disposition knowing I cannot
afford to loose a message (Financial Services).

The overall idea would be to create that chain:  publisher (Java/qpid-JMS
or C++/Qpid Messaging) --> routers --> brokers (prefered option java, if
not C++ is fine) --> routers --> consumers (Java / qpid-JMS)

For sure this will not be straight forward but it seems doable? no?

oliv/

On Wed, Dec 2, 2015 at 5:18 PM, Ted Ross <tr...@redhat.com> wrote:

> Dispatch does support the full AMQP link protocol (settlement and
> disposition).
>
> -Ted
>
>
> On 12/02/2015 11:15 AM, Gibson, Jack wrote:
>
>> You could possibly just use settlements and acknowledgements not sure of
>> the support with dispatch for that. At least you could manage some level
>> of delivery guarantees.
>>
>> Jack Gibson
>> Chief Architect
>> Core Payments Platforms/PayPal
>>
>>
>>
>> On 12/2/15, 7:22 AM, "Ted Ross" <tr...@redhat.com> wrote:
>>
>> As Jack correctly pointed out, this is currently a missing feature in
>>> Dispatch Router.  There is a Jira
>>> (https://issues.apache.org/jira/browse/DISPATCH-195) open to track the
>>> issue.
>>>
>>> In your use case, are you using routed links (i.e. with linkRoutePattern
>>> in your router configuration)?
>>>
>>> Also, since your use case involves a database, are you expecting support
>>> for XA or distributed transactions?  We plan to add local transactions
>>> (client-to-broker, or endpoint-to-endpoint) in the near future but
>>> distributed transactions will take longer.
>>>
>>> -Ted
>>>
>>> On 12/01/2015 06:52 PM, Olivier Mallassi wrote:
>>>
>>>> hello all
>>>>
>>>> I was wondering if qpid dispatch was supporting trnasaction. in fact the
>>>> pattern I would need to implement is the following (a classic one)
>>>>
>>>> Publisher (java/c++)
>>>> beginTransaction > insert rdbms > publish msg > commit
>>>>
>>>> the amqp infra would be dispatch + java qpid broker.
>>>>
>>>> I assume it works. Can someone confirm please?
>>>>
>>>> Thx for your help
>>>>
>>>> olivier.
>>>>
>>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

qpid dispatch & transaction

[Olivier Mallassi]

hello all

I was wondering if qpid dispatch was supporting trnasaction. in fact the
pattern I would need to implement is the following (a classic one)

Publisher (java/c++)
beginTransaction > insert rdbms > publish msg > commit

the amqp infra would be dispatch + java qpid broker.

I assume it works. Can someone confirm please?

Thx for your help

olivier.