qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Apache Qpid Dispatch Router 0.6.0 Release Candidate 1 now available
Date Mon, 09 May 2016 13:14:41 GMT
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\xa1@request.ABCFR_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 <jakub@scholz.cz> 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 <tross@redhat.com> 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: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message