On more issue I noticed ... when the policy doesn't allow to link against some source / target address, it seems to always return amqp;:resource-limit-exceeded error. I think that amqp:unauthorized-access is the one which should be used in this particular case. Agsain, this is not necesarilly a blocker.
Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 <- @attach(18) [name="request.ABCFR_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="request.ABCFR_ABCFRALMMACC1", durable=0, timeout=0, dynamic=false], target=@target(41) [address="request.ABCFR_ABCFRALMMACC1", durable=0, timeout=0, dynamic=false, capabili ties=:topic], initial-delivery-count=0] Mon May 9 09:12:47 2016 POLICY (info) DENY AMQP Attach sender link 'request.ABCFR_ABCFRALMMACC1' for user 'admin@QPID', host '127.0.0.1', app '(null)' based on link target name Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 -> @attach(18) [name="request.ABCFR_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] Mon May 9 09:12:47 2016 SERVER (trace) [4]:RAW: "\x00\x00\x00\x8f\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00\x7f\x00\x00\x00\x0a\[email protected]_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1R \x00AP\x02P\x00\x00S(\xd0\x00\x00\x00\x11\x00\x00\x00\x0b@R\x00@R\x00B@ @@@@@\x00S)\xd0\x00\x00\x00\x0d\x00\x00\x00\x07@R\x00@R\x00B@@@@R\x00" Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 -> @detach(22) [handle=0, closed=true, error=@error(29) [condition=:"amqp:resource-limit-exceeded", description="link disallowed by local policy"]] Mon May 9 09:12:47 2016 SERVER (trace) [4]:RAW: "\x00\x00\x00c\x02\x00\x00\x00\x00S\x16\xd0\x00\x00\x00S\x00\x00\x00\x03R\x00A\x00S\x1d\xd0\x00\x00\x00D\x00\x00\x00\x03\xa3\x1camqp:resource-limit-exceeded\xa1\x1flink disallowed by local policy@" On Mon, May 9, 2016 at 9:55 AM, Jakub Scholz <[email protected]> wrote: > Hi Ted, > > I played with the RC for one of my usecases - receiving/sending messages > between a client and broker through Dispatch. Works quite nicely. > > Some minor issues which I noticed - not necessarily blocking issues: > 1) If I want to use link routing the direction "in" means the client is > sending messages and the direction "out" means client is receiving > messages. However when using the autoLinks, the "in" direction means the > client is receiving and the "out" direction means the client is sending. I > guess this might have some logic from other pespective, but for me it was a > bit confusing. > 2) The connector which is using the SSL to connect to the broker doesn't > seem to do hostname verification. It would be great if the hostname > verification would be done by default but could be switched off. > 3) When I setup a listener to use SASL authentication using username and > password, it doesn't seem to send out the SASL-OUTCOME frame. When I > connect with wrong password to the C++ broker, the broker sends back > SASL-OUTCOME indicating the failure and the client knows that the > authentication failed. However, Dispatch seems to close the connection > without sending the SASL-OUTCOME and therefore the client reports only > generic connection loss. > > C++ broker: > 2016-05-09 03:06:23 [Protocol] debug tcp:cbgc01.xeop.de:29700 writing > protocol header: 1-0 > 2016-05-09 03:06:23 [Protocol] debug tcp:cbgc01.xeop.de:29700 read > protocol header: 1-0 > 2016-05-09 03:06:23 [Protocol] debug tcp:cbgc01.xeop.de:29700 Received > SASL-MECHANISMS(CRAM-MD5 PLAIN DIGEST-MD5 ) > 2016-05-09 03:06:23 [Protocol] debug tcp:cbgc01.xeop.de:29700 Sent > SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, cbgc01.xeop.de) > 2016-05-09 03:06:23 [Protocol] debug tcp:cbgc01.xeop.de:29700 Received > SASL-OUTCOME(\x01) > qpid-receive: Authentication failed > > Dispatch: > 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol > header: 1-0 > 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol > header: 1-0 > 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received > SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 ) > 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent > SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost) > qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled > > Also the DISPATCH-155 <https://issues.apache.org/jira/browse/DISPATCH-155> > JIRA is causing problems in my usecase, but that can for sure wait for next > release. > > The configuation I used can be found here: > https://github.com/Eurex-Clearing-Messaging-Interfaces/Dispatch-Examples > > Thanks & Regards > Jakub > > On Thu, May 5, 2016 at 10:26 PM, Ted Ross <[email protected]> wrote: > >> The first release candidate for Apache Qpid Dispatch Router 0.6.0 is >> available for testing. You can find the files here: >> >> https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.6.0-rc1/ >> >> This is not the final release candidate because Robbie and Ganesh have >> already identified important updates that are still needed. RC2 should be >> available in a couple of days and hopefully we can vote on that one. >> >> This update includes the fixes to numerous issues that were discovered >> during testing of the beta-2 release. Please see the wiki page below for a >> list of resolved issues. >> >> >> >> https://cwiki.apache.org/confluence/display/qpid/What%27s+New+in+Apache+Qpid+Dispatch+Router+0.6.0 >> >> Regards, >> >> -Ted >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
