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] > >
