Re: [Router][Java Broker] connect failed between Router & Java Broker
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 wrote:
> You should turn on the proton trace for the router to get more detailed
> information about what is happening. To get even more detailed, you can
> use tcpdump to get a trace of the communication.
>
> PN_TRACE_FRM=1 qdrouterd ...
>
> -Ted
>
>
> On 12/07/2015 02:40 PM, Olivier Mallassi wrote:
>
>> 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&remote-host=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.
>>
>>
> -
> 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
You should turn on the proton trace for the router to get more detailed
information about what is happening. To get even more detailed, you can
use tcpdump to get a trace of the communication.
PN_TRACE_FRM=1 qdrouterd ...
-Ted
On 12/07/2015 02:40 PM, Olivier Mallassi wrote:
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&remote-host=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.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
[Router][Java Broker] connect failed between Router & Java Broker
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&remote-host=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.
Re: [JMS] [AMQP 1.0] link definition and guarantee delivery
@Robbie, thank you for clarification
On Mon, Dec 7, 2015 at 1:07 PM, Robbie Gemmell
wrote:
> On 4 December 2015 at 19:09, Olivier Mallassi
> 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.
> >
> > 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?
> >
>
> The new AMQP 1.0 client is entirely distinct from the earlier 0-x
> client and does not support the old 'address syntax' it used.
> Documentation for the client c
Re: [VOTE] Release Qpid Java Components 6.0.0
+1 On 03/12/15 15:06, Oleksandr Rudyy wrote: Hi folks, I would like to initiate new voting to release Qpid Java Components 6.0.0 RC5 as the final 6.0.0. Maven release artifacts are available from maven staging repo at: https://repository.apache.org/content/repositories/orgapacheqpid-1056 Source and binary bundles are available from dev staging area at: https://dist.apache.org/repos/dist/dev/qpid/java/6.0.0-rc5/ Please indicate your vote below. If you favor releasing the 6.0.0 RC5 artifacts as 6.0.0 GA, vote +1. If you have reason to think RC5 is not ready for release, vote -1. This vote will be closes at 17:00 UTC on Tuesday 8th of December. Kind Regards, Alex - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: qpid dispatch & transaction
On Fri, 2015-12-04 at 15:19 -0500, Ted Ross wrote: > Olivier, > > Please be advised that the Messenger API in proton is not getting a > lot > of developer attention. The development effort has shifted to the > reactive APIs and it's likely that the reactive interfaces are what > are > going to be best supported in the future. > > The Messenger API is quite abstract (hides the concepts of > connection, > session, and link) and is therefore appealing for simple use cases. > In > practice, however, it's been found to be difficult to integrate into > real environments. It also has some significant limits in its error reporting and handling. Those could be addressed eventually, but as Ted says, the focus has shifted to the reactive APIs. They offer more of a a "sliding scale" in terms of ease-of-use vs. flexiblity: It is still pretty easy to do simple things, but there is an open path to learning more and digging deep into the protocol details if/when you need to. > > -Ted > > On 12/04/2015 02:11 PM, Olivier Mallassi wrote: > > Thanks Ted. > > > > I have found this > > https://github.com/apache/qpid-proton/blob/master/docs/markdown/mes > > senger/addressing-and-routing.md > > may be useful. > > > > On Thu, Dec 3, 2015 at 9:13 PM, Ted Ross 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 > > > > 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" 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++) > > > > > > > > beginTransac
Re: [JMS] [AMQP 1.0] link definition and guarantee delivery
On 4 December 2015 at 19:09, Olivier Mallassi
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.
>
> 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?
>
The new AMQP 1.0 client is entirely distinct from the earlier 0-x
client and does not support the old 'address syntax' it used.
Documentation for the client can be found on the website, e.g
http://qpid.apache.org/releases/qpid-jms-0.6.0/docs/index.html for the
current release.
The "queue." and "topic." entries documented are all that the new
client currently supports, with the entry value currently mapping
directly to the AMQP 1.0 node 'address' as you have seen.
Possibly adding e
