You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Bruno Matos <br...@paradigmaxis.pt> on 2013/05/09 14:52:19 UTC
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
On Seg, 2013-03-11 at 11:56 +0000, Gordon Sim wrote:
> On 02/25/2013 06:57 PM, Bruno Matos wrote:
> > On Sex, 2013-02-15 at 18:22 +0000, Gordon Sim wrote:
> >> On 02/07/2013 12:34 PM, Gordon Sim wrote:
> >>> On 02/04/2013 06:23 PM, Gordon Sim wrote:
> >>>> On 02/04/2013 04:59 PM, Steve Huston wrote:
> >>>>> Is there a chance you'll be able to make progress on this area of Qpid
> >>>>> sufficiently to raise the topics at the Feb 18 AMQP F2F? Are you
> >>>>> planning to go?
> >>>>
> >>>> To get it into 0.22 it really needs to be mostly done by the alpha in
> >>>> mid-feb, so yes I would hope to have something usable in svn by that
> >>>> time.
> >>>>
> >>>> I am not able to attend the F2F sadly, but do plan on putting my
> >>>> thoughts in a mail to the TC list (I'll post it here as well).
> >>>
> >>> As promised, I've attached some of my thoughts on addressing. I'm
> >>> posting these to the OASIS AMQP TC list as well.
> >>>
> >>> Comments, corrections, criticisms are all welcome!
> >>
> >> I have an initial patch that adds the ability to have qpidd initiate
> >> AMQP 1.0 connections (and links) to some external entity (e.g. another
> >> 1.0 supporting broker).
> >>
> >> It isn't quite ready to be committed yet I'm afraid, but for those
> >> interested more detail can be found at
> >> https://reviews.apache.org/r/9469/ along with the current patch.
> >>
> >
> > I have compiled qpidd with the patch, how can I "Interconnect" two
> > brokers now?
>
> [Apologies for the much delayed response].
>
> You first need to create a 'domain' on the broker that will initiate the
> connection to the other. This essentially defines how to connect. This
> is done through the 'create' QMF 'method' on the broker, using 'domain'
> as the type. The valid properties are 'url, 'username', 'password',
> 'sasl_mechanisms (and less frequently needed min_ssf. max_ssf,
> sasl_service).
>
> At present you can do this either via qpid-tool or using the qpid-ctrl
> test utility[1]. E.g.
>
> qpid-ctrl create type=domain name=my-domain
> properties="{'url':'broker2.acme.org','mechanisms':'NONE'}"
>
> Next, you can statically set up incoming or outgoing links from the
> first broker to this 'domain'. You do that by again using the QMF
> 'create' method, but this type using a type of either 'incoming' or
> 'outgoing', depending on the desired direction of message flow. The
> valid properties for both types are 'domain', 'source' and 'target'
>
> E.g. qpid-ctrl create type=outgoing name=my-outgoing-link
> properties="{'domain':'my-domain','source':'amq.topic','target':'amq.topic'}"
>
> There will be better tooling available for this eventually.
>
> Alternatively, you can also simply relay through the broker to a defined
> domain without any statically setup links. To do this you simply append
> the domain name to the node you wish to send to. E.g. creating a sender
> on a session with the first broker to e.g. my-queue@my-domain, will
> result in the messages being relayed to my-queue on the second broker.
>
> I.e. you can access nodes actually implemented in some other AMQP 1.0
> container (whether another qpidd, a different 1.0 capable broker or even
> a proton messenger service) to be accessed as if they were in the one
> broker the client is connected to.
>
> [1] https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/tests/qpid-ctrl
Hi Gordon,
Finally I have some time to test domains.
I'm trying to create a link between two Brokers 0.22 RC2, but I'm having
two errors, with the same origin, creating the outgoing link that I
don't know how to solve. I'm using qpid-ctrl as you suggested.
1. If I set --auth yes (on both), I receive the error "SASL layer
required!", I took a look to the code and it seams the it was expecting
SASL as the protocol and it has AMQP.
2. If I set --auth no (on both), the connection closes by timeout (10s)
on the destination broker and it gives "No protocol received closing",
which produces a "Interconnect deleted" notice on the source broker.
What am I'm I doing wrong?
Thank you,
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Seg, 2013-05-13 at 14:31 +0100, Bruno Matos wrote:
> On Seg, 2013-05-13 at 12:17 +0100, Gordon Sim wrote:
> > On 05/13/2013 11:59 AM, Bruno Matos wrote:
> > > On Qui, 2013-05-09 at 16:02 +0100, Gordon Sim wrote:
> > >> On 05/09/2013 03:13 PM, Bruno Matos wrote:
> > >>> The same, after 10 minutes it gives:
> > >>> error Connection qpid.192.168.102.104:5672-192.168.102.7:50729 No
> > >>> protocol received closing
> > >>>
> > >>> Be aware that this is a local compilation with no install, something can
> > >>> be wrong with modules or something else, not that I have notice, but it
> > >>> can.
> > >>
> > >> Hmm... did you use autotools or cmake? If you run: make check
> > >> TESTS=run_interlink_tests (if using autotools) or ctest -R interlink (if
> > >> using cmake) do the tests all pass?
> > >
> > > I'm using cmake, and the interlink tests failed indeed, I'll try to
> > > understand why, and I'll let you know.
> > >
> > > They failed on SL6.3, but they pass on FC18.
> >
> > Is it the same version of proton in each case? Do they all fail or just
> > some of them?
>
> Sorry to waste your time, it was my fault, as expected... One had an old
> qpid version that was conflicting with the new one and the other didn't
> have qpid libraries in the python's library path. Now all tests pass,
> but the problem is still there, if I don't set the --max-negotiate-time,
> 10 seconds after the outgoing link creation, the destination broker
> gives 'error Connection qpid.192.168.102.104:5672-192.168.102.7:52067 No
> protocol received closing' and it's deleted in the source broker.
>
Update: If I set the --max-negotiate-time to 10 minutes, it gives the
same error.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Sex, 2013-05-24 at 16:48 +0100, Gordon Sim wrote:
> On 05/24/2013 04:44 PM, Bruno Matos wrote:
> > This requirement, having username and password on properties and not
> > directly in url are AMQP 1.0 protocol specific or is just an
> > implementation choice?
>
> Its really just an oversight on my part. If you assign me a JIRA I'll
> fix that.
Done: https://issues.apache.org/jira/browse/QPID-4887
Thank you.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/24/2013 04:44 PM, Bruno Matos wrote:
> This requirement, having username and password on properties and not
> directly in url are AMQP 1.0 protocol specific or is just an
> implementation choice?
Its really just an oversight on my part. If you assign me a JIRA I'll
fix that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Sex, 2013-05-24 at 16:33 +0100, Gordon Sim wrote:
> On 05/24/2013 04:30 PM, Bruno Matos wrote:
> > With the module loaded and 1.0 selected, something goes wrong again in
> > the handshake, maybe a miss configuration. SASL it's complaining about
> > no mechanisms available. I'll take a closer look.
>
> Did you set username and password in the connection options?
>
They were (again) only in the connection string, now it's working. This
requirement, having username and password on properties and not directly
in url are AMQP 1.0 protocol specific or is just an implementation
choice?
Thank you.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/24/2013 04:30 PM, Bruno Matos wrote:
> With the module loaded and 1.0 selected, something goes wrong again in
> the handshake, maybe a miss configuration. SASL it's complaining about
> no mechanisms available. I'll take a closer look.
Did you set username and password in the connection options?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-23 at 16:33 +0100, Gordon Sim wrote:
> On 05/23/2013 04:24 PM, Bruno Matos wrote:
> > On Qui, 2013-05-23 at 15:45 +0100, Gordon Sim wrote:
> >> On 05/23/2013 02:23 PM, Bruno Matos wrote:
> >>> Yes, I'm using 0.22 RC3 with the patch from revision 1485467.
> >>> I've created the domain like this
> >>>
> >>> ./qpid-ctrl create type=domain name=my-domain
> >>> properties="{'url':'B','sasl_mechanisms':'PLAIN','username':'someuser','password':'somepass'}" -b someuser/somepass@A
> >>>
> >>> Created a queue on B with name 'queue2'.
> >>>
> >>> Then I send a message to queue2@my-domain to broker A and it complains:
> >>>
> >>> Exception received from broker: not-found: not-found: Queue not found:
> >>> queue2@my-domain
> >>
> >> Is the sender created on a 1.0 connection? (This does not at present
> >> work for 0-10).
> >>
> >
> > No the sender is using 0-10. The only way to use 1.0 is using proton?
>
> The 1.0 support in qpid::messaging relies on proton, yes. But presumably
> you have that already since the domain stuff is only available with 1.0
> also.
>
> You can still use the qpid::messaging API though. You just need to load
> the amqpc.so lib on the client and specify 'protocol:amqp1.0' in the
> connection-options.
>
With the module loaded and 1.0 selected, something goes wrong again in
the handshake, maybe a miss configuration. SASL it's complaining about
no mechanisms available. I'll take a closer look.
In attachment are the client logs, if you want to take a look.
Thank you.
--
Bruno Matos
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/23/2013 04:24 PM, Bruno Matos wrote:
> On Qui, 2013-05-23 at 15:45 +0100, Gordon Sim wrote:
>> On 05/23/2013 02:23 PM, Bruno Matos wrote:
>>> Yes, I'm using 0.22 RC3 with the patch from revision 1485467.
>>> I've created the domain like this
>>>
>>> ./qpid-ctrl create type=domain name=my-domain
>>> properties="{'url':'B','sasl_mechanisms':'PLAIN','username':'someuser','password':'somepass'}" -b someuser/somepass@A
>>>
>>> Created a queue on B with name 'queue2'.
>>>
>>> Then I send a message to queue2@my-domain to broker A and it complains:
>>>
>>> Exception received from broker: not-found: not-found: Queue not found:
>>> queue2@my-domain
>>
>> Is the sender created on a 1.0 connection? (This does not at present
>> work for 0-10).
>>
>
> No the sender is using 0-10. The only way to use 1.0 is using proton?
The 1.0 support in qpid::messaging relies on proton, yes. But presumably
you have that already since the domain stuff is only available with 1.0
also.
You can still use the qpid::messaging API though. You just need to load
the amqpc.so lib on the client and specify 'protocol:amqp1.0' in the
connection-options.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-23 at 15:45 +0100, Gordon Sim wrote:
> On 05/23/2013 02:23 PM, Bruno Matos wrote:
> > Yes, I'm using 0.22 RC3 with the patch from revision 1485467.
> > I've created the domain like this
> >
> > ./qpid-ctrl create type=domain name=my-domain
> > properties="{'url':'B','sasl_mechanisms':'PLAIN','username':'someuser','password':'somepass'}" -b someuser/somepass@A
> >
> > Created a queue on B with name 'queue2'.
> >
> > Then I send a message to queue2@my-domain to broker A and it complains:
> >
> > Exception received from broker: not-found: not-found: Queue not found:
> > queue2@my-domain
>
> Is the sender created on a 1.0 connection? (This does not at present
> work for 0-10).
>
No the sender is using 0-10. The only way to use 1.0 is using proton?
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/23/2013 02:23 PM, Bruno Matos wrote:
> Yes, I'm using 0.22 RC3 with the patch from revision 1485467.
> I've created the domain like this
>
> ./qpid-ctrl create type=domain name=my-domain
> properties="{'url':'B','sasl_mechanisms':'PLAIN','username':'someuser','password':'somepass'}" -b someuser/somepass@A
>
> Created a queue on B with name 'queue2'.
>
> Then I send a message to queue2@my-domain to broker A and it complains:
>
> Exception received from broker: not-found: not-found: Queue not found:
> queue2@my-domain
Is the sender created on a 1.0 connection? (This does not at present
work for 0-10).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-23 at 14:10 +0100, Gordon Sim wrote:
> On 05/23/2013 02:03 PM, Bruno Matos wrote:
> > It should work now, with the domains configured with qpid-ctrl and a
> > sender created with my-queue@my-domain ? In the test I run it complains
> > that there is no such queue.
>
> Yes, if my-queue exists on the broker identified by my-domain then
> sending to that should work. You're using a 0.22 RC, right?
Yes, I'm using 0.22 RC3 with the patch from revision 1485467.
I've created the domain like this
./qpid-ctrl create type=domain name=my-domain
properties="{'url':'B','sasl_mechanisms':'PLAIN','username':'someuser','password':'somepass'}" -b someuser/somepass@A
Created a queue on B with name 'queue2'.
Then I send a message to queue2@my-domain to broker A and it complains:
Exception received from broker: not-found: not-found: Queue not found:
queue2@my-domain
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/23/2013 02:03 PM, Bruno Matos wrote:
> It should work now, with the domains configured with qpid-ctrl and a
> sender created with my-queue@my-domain ? In the test I run it complains
> that there is no such queue.
Yes, if my-queue exists on the broker identified by my-domain then
sending to that should work. You're using a 0.22 RC, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-23 at 13:20 +0100, Gordon Sim wrote:
> On 05/23/2013 11:08 AM, Bruno Matos wrote:
> > My motivation to use the domain feature has to do with sending messages
> > from a service connected to source broker directly to a queue in
> > destination broker, if you remember my first questions about it. But I
> > don't know how can achieve that.
>
> So, just to ensure I understand correctly, you have a service that
> subscribes to a request queue on broker A and a client that wants to use
> that service, connected to broker B. The client sends a message that
> should be transmitted across from B to A. The message contains a reply
> to that refers to a queue on B and responses should go there.
>
Yes, that's it.
> To achieve this with 0-10 based federation, you need to have the
> response queue bound to some explicit exchange (not simply the default
> exchange) and use that exchange in the reply-to address (along with a
> unique binding/routing key if the exchange is shared by other
> responses). E.g. create a 'responses' exchange (as a direct exchange)
> and then use 'response/#' as the address for the response receiver,
> passing the generated unique address in as the reply-to.
>
> Part of the goals of the 1.0 federation equivalent was to make this more
> seamless/transparent and less dependent on pre 1.0 exchange types. You
> can configure each broker to know about the other (i.e. setup a domain),
> and then access queues on another broker through
> <queue-name>@<broker-name>. So for a my-responses queue on broker B,
> broker A could access that directly as my-responses@BrokerB (assuming a
> domain named BrokerB has been configured with the details of how to
> connect).
It should work now, with the domains configured with qpid-ctrl and a
sender created with my-queue@my-domain ? In the test I run it complains
that there is no such queue.
>
> The next step is to make the qualification of the queue name by domain
> more transparent. For temp queues in 1.0, the broker assigns the name
> and passes this back to the client and the broker can be configured to
> add the necessary qualification transparently. I've just committed a fix
> to trunk that makes that work in such a way as to allow the
> client/server example shipped with the c++ messaging client to be able
> to be run against a pair of brokers without changing the examples
> themselves. That isn't possible yet on 0.20 (or 0.22) though I'm afraid,
> but hopefully it gives some idea of the motivation and direction.
>
> And of course this is not limited to reply queues. You can use this to
> access nodes of any type in any other process that accepts 1.0
> connections. E.g. if you have systems using ActiveMQ or SwiftMQ and need
> access to a particular piece of functionality or a particular
> source/sink for messages on those from clients connected to qpidd you
> can do that quite simply also (or even access a standalone proton based
> service).
>
Thank you.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/23/2013 11:08 AM, Bruno Matos wrote:
> My motivation to use the domain feature has to do with sending messages
> from a service connected to source broker directly to a queue in
> destination broker, if you remember my first questions about it. But I
> don't know how can achieve that.
So, just to ensure I understand correctly, you have a service that
subscribes to a request queue on broker A and a client that wants to use
that service, connected to broker B. The client sends a message that
should be transmitted across from B to A. The message contains a reply
to that refers to a queue on B and responses should go there.
To achieve this with 0-10 based federation, you need to have the
response queue bound to some explicit exchange (not simply the default
exchange) and use that exchange in the reply-to address (along with a
unique binding/routing key if the exchange is shared by other
responses). E.g. create a 'responses' exchange (as a direct exchange)
and then use 'response/#' as the address for the response receiver,
passing the generated unique address in as the reply-to.
Part of the goals of the 1.0 federation equivalent was to make this more
seamless/transparent and less dependent on pre 1.0 exchange types. You
can configure each broker to know about the other (i.e. setup a domain),
and then access queues on another broker through
<queue-name>@<broker-name>. So for a my-responses queue on broker B,
broker A could access that directly as my-responses@BrokerB (assuming a
domain named BrokerB has been configured with the details of how to
connect).
The next step is to make the qualification of the queue name by domain
more transparent. For temp queues in 1.0, the broker assigns the name
and passes this back to the client and the broker can be configured to
add the necessary qualification transparently. I've just committed a fix
to trunk that makes that work in such a way as to allow the
client/server example shipped with the c++ messaging client to be able
to be run against a pair of brokers without changing the examples
themselves. That isn't possible yet on 0.20 (or 0.22) though I'm afraid,
but hopefully it gives some idea of the motivation and direction.
And of course this is not limited to reply queues. You can use this to
access nodes of any type in any other process that accepts 1.0
connections. E.g. if you have systems using ActiveMQ or SwiftMQ and need
access to a particular piece of functionality or a particular
source/sink for messages on those from clients connected to qpidd you
can do that quite simply also (or even access a standalone proton based
service).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qua, 2013-05-22 at 23:29 +0100, Gordon Sim wrote:
> On 05/22/2013 04:58 PM, Bruno Matos wrote:
> > I don't know if this is the problem, but the decoder is reading the AMQP
> > as if it was the size of the message. Could you please confirm?
>
> Yes, that is correct. The incoming frames are not decoded because there
> is an extraneous protocol header in the stream that is interpreted as a
> a framesize larger than the available bytes.
>
> Bruno, thank you so much for investigating this and finding the issues.
> I have created a JIRA and committed a fix:
> http://svn.apache.org/viewvc?view=revision&revision=r1485467. That fix
> should I hope apply to 0.20 as well if you want to try it out there.
>
> Once again, thank you for all your help and patience on this and I do
> apologise both for the bugs and for the time it has taken me to get
> round to resolving them.
>
Thank you, it's working now.
My motivation to use the domain feature has to do with sending messages
from a service connected to source broker directly to a queue in
destination broker, if you remember my first questions about it. But I
don't know how can achieve that.
PS: Your work and your help contributes more to my work than mine to
yours, so thank you! :)
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/22/2013 04:58 PM, Bruno Matos wrote:
> I don't know if this is the problem, but the decoder is reading the AMQP
> as if it was the size of the message. Could you please confirm?
Yes, that is correct. The incoming frames are not decoded because there
is an extraneous protocol header in the stream that is interpreted as a
a framesize larger than the available bytes.
Bruno, thank you so much for investigating this and finding the issues.
I have created a JIRA and committed a fix:
http://svn.apache.org/viewvc?view=revision&revision=r1485467. That fix
should I hope apply to 0.20 as well if you want to try it out there.
Once again, thank you for all your help and patience on this and I do
apologise both for the bugs and for the time it has taken me to get
round to resolving them.
--Gordon.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Ter, 2013-05-21 at 16:29 +0100, Gordon Sim wrote:
> On 05/21/2013 03:39 PM, Bruno Matos wrote:
> > On Ter, 2013-05-21 at 15:19 +0100, Gordon Sim wrote:
> >> On 05/21/2013 03:13 PM, Bruno Matos wrote:
> >>> On Ter, 2013-05-21 at 15:06 +0100, Gordon Sim wrote:
> >>>
> >>> trace+:Protocol
> >>
> >> That should do it... were you using a file or redirecting std out? (As
> >> mentioned, unfortunately the tracing for 1.0 is done by the proton
> >> library itself and doesn't yet honour any file options).
> >
> > I was redirecting to std out. I can make a network capture to confirm
> > the number of packets exchanged if you think it could help.
>
>
> Sorry, its my mistake! The SASL commands are *not* handled by proton, so
> are not logged the same way.
>
> So it is indeed the case that the destination is not receiving the
> sasl-init I believe. Why that is the case I'm not sure but will dig into
> it very shortly... (I promise!).
>
I don't know if this is the problem, but the decoder is reading the AMQP
as if it was the size of the message. Could you please confirm?
Thank you,
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/21/2013 03:39 PM, Bruno Matos wrote:
> On Ter, 2013-05-21 at 15:19 +0100, Gordon Sim wrote:
>> On 05/21/2013 03:13 PM, Bruno Matos wrote:
>>> On Ter, 2013-05-21 at 15:06 +0100, Gordon Sim wrote:
>>>
>>> trace+:Protocol
>>
>> That should do it... were you using a file or redirecting std out? (As
>> mentioned, unfortunately the tracing for 1.0 is done by the proton
>> library itself and doesn't yet honour any file options).
>
> I was redirecting to std out. I can make a network capture to confirm
> the number of packets exchanged if you think it could help.
Sorry, its my mistake! The SASL commands are *not* handled by proton, so
are not logged the same way.
So it is indeed the case that the destination is not receiving the
sasl-init I believe. Why that is the case I'm not sure but will dig into
it very shortly... (I promise!).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Ter, 2013-05-21 at 15:19 +0100, Gordon Sim wrote:
> On 05/21/2013 03:13 PM, Bruno Matos wrote:
> > On Ter, 2013-05-21 at 15:06 +0100, Gordon Sim wrote:
> >
> > trace+:Protocol
>
> That should do it... were you using a file or redirecting std out? (As
> mentioned, unfortunately the tracing for 1.0 is done by the proton
> library itself and doesn't yet honour any file options).
I was redirecting to std out. I can make a network capture to confirm
the number of packets exchanged if you think it could help.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/21/2013 03:13 PM, Bruno Matos wrote:
> On Ter, 2013-05-21 at 15:06 +0100, Gordon Sim wrote:
>> On 05/21/2013 02:58 PM, Bruno Matos wrote:
>>> On Ter, 2013-05-21 at 12:08 +0100, Gordon Sim wrote:
>>>> Can you post the protocol trace for the handshaking?
>>>
>>> They are in attachment from both source and destination brokers.
>>
>> It doesn't actually contain the 1.0 protocol traces... what logging
>> options did you use? (From the debug it looks like the destination did
>> not get the init and did not therefore send the outcome).
>>
>
> trace+:Protocol
That should do it... were you using a file or redirecting std out? (As
mentioned, unfortunately the tracing for 1.0 is done by the proton
library itself and doesn't yet honour any file options).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Ter, 2013-05-21 at 15:06 +0100, Gordon Sim wrote:
> On 05/21/2013 02:58 PM, Bruno Matos wrote:
> > On Ter, 2013-05-21 at 12:08 +0100, Gordon Sim wrote:
> >> On 05/21/2013 11:14 AM, Bruno Matos wrote:
> >>> It needs the username and password properties set on domain creation, I
> >>> thought they were parsed from url.
> >>>
> >>> Now, with SASL it doesn't create the queue for the outgoing link. This
> >>> is because when qpid::broker::amqp::Sasl::canEncode() is called the
> >>> state is NONE so it doesn't call the Connection::canEncode which would
> >>> create the queue as when there is no SASL layer and Wrapper::canEncode
> >>> is called.
> >>>
> >>> If at this point I stop the source broker, the destination broker gives
> >>> 'Connection closed prior to authentication completing' twice, which
> >>> makes me think that authentication or the handshake were never finished.
> >>
> >> Can you post the protocol trace for the handshaking?
> >
> > They are in attachment from both source and destination brokers.
>
> It doesn't actually contain the 1.0 protocol traces... what logging
> options did you use? (From the debug it looks like the destination did
> not get the init and did not therefore send the outcome).
>
trace+:Protocol
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/21/2013 02:58 PM, Bruno Matos wrote:
> On Ter, 2013-05-21 at 12:08 +0100, Gordon Sim wrote:
>> On 05/21/2013 11:14 AM, Bruno Matos wrote:
>>> It needs the username and password properties set on domain creation, I
>>> thought they were parsed from url.
>>>
>>> Now, with SASL it doesn't create the queue for the outgoing link. This
>>> is because when qpid::broker::amqp::Sasl::canEncode() is called the
>>> state is NONE so it doesn't call the Connection::canEncode which would
>>> create the queue as when there is no SASL layer and Wrapper::canEncode
>>> is called.
>>>
>>> If at this point I stop the source broker, the destination broker gives
>>> 'Connection closed prior to authentication completing' twice, which
>>> makes me think that authentication or the handshake were never finished.
>>
>> Can you post the protocol trace for the handshaking?
>
> They are in attachment from both source and destination brokers.
It doesn't actually contain the 1.0 protocol traces... what logging
options did you use? (From the debug it looks like the destination did
not get the init and did not therefore send the outcome).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Ter, 2013-05-21 at 12:08 +0100, Gordon Sim wrote:
> On 05/21/2013 11:14 AM, Bruno Matos wrote:
> > It needs the username and password properties set on domain creation, I
> > thought they were parsed from url.
> >
> > Now, with SASL it doesn't create the queue for the outgoing link. This
> > is because when qpid::broker::amqp::Sasl::canEncode() is called the
> > state is NONE so it doesn't call the Connection::canEncode which would
> > create the queue as when there is no SASL layer and Wrapper::canEncode
> > is called.
> >
> > If at this point I stop the source broker, the destination broker gives
> > 'Connection closed prior to authentication completing' twice, which
> > makes me think that authentication or the handshake were never finished.
>
> Can you post the protocol trace for the handshaking?
They are in attachment from both source and destination brokers.
>
> > Could you please help me understand if something is wrong with my
> > configuration or clarify this authentication/handshake process and what
> > may be wrong?
>
> I suspect a bug (or two) in the code (obviously there is at least one,
> that which you fixed already) where SASL and interlinks combine. I'm
> sorry I haven't responded more positively, I've been trying to finish
> off another piece of work. I will get on to this as soon as that is
> done. (And thanks very much for all your help and insight on the issue
> so far).
>
I'm glad I could help, as little as my contribution has been.
Regards.
--
Bruno Matos
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/21/2013 11:14 AM, Bruno Matos wrote:
> It needs the username and password properties set on domain creation, I
> thought they were parsed from url.
>
> Now, with SASL it doesn't create the queue for the outgoing link. This
> is because when qpid::broker::amqp::Sasl::canEncode() is called the
> state is NONE so it doesn't call the Connection::canEncode which would
> create the queue as when there is no SASL layer and Wrapper::canEncode
> is called.
>
> If at this point I stop the source broker, the destination broker gives
> 'Connection closed prior to authentication completing' twice, which
> makes me think that authentication or the handshake were never finished.
Can you post the protocol trace for the handshaking?
> Could you please help me understand if something is wrong with my
> configuration or clarify this authentication/handshake process and what
> may be wrong?
I suspect a bug (or two) in the code (obviously there is at least one,
that which you fixed already) where SASL and interlinks combine. I'm
sorry I haven't responded more positively, I've been trying to finish
off another piece of work. I will get on to this as soon as that is
done. (And thanks very much for all your help and insight on the issue
so far).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Seg, 2013-05-20 at 11:13 +0100, Bruno Matos wrote:
> On Sex, 2013-05-17 at 15:24 +0100, Gordon Sim wrote:
> > > I'm using PLAIN in the domain configuration. I was debugging the
> > > creation of the messages in the source broker and notice that the
> > > qpid::broker::amqp::SaslClient::getVersion calls the
> > > Connection::getVersion method which creates a ProtocolVersion(1,0),
> > > leaving the protocol field of ProtocolVersion set to 0. Can this be a
> > > problem?
> >
> > Yes!
> >
> > > After change that to ProtocolVersion(1,0,3) the destination
> > > broker no longer complains about SASL layer.
> >
> > Great... and does it then work?
>
> No, the source broker throws an exception on qpid::CyrusSasl::start
> +311. In debug mode, I inspected some variables and it seams that
> something is missing, I was expecting to see username and password in
> conn p.e but it's not set.
>
It needs the username and password properties set on domain creation, I
thought they were parsed from url.
Now, with SASL it doesn't create the queue for the outgoing link. This
is because when qpid::broker::amqp::Sasl::canEncode() is called the
state is NONE so it doesn't call the Connection::canEncode which would
create the queue as when there is no SASL layer and Wrapper::canEncode
is called.
If at this point I stop the source broker, the destination broker gives
'Connection closed prior to authentication completing' twice, which
makes me think that authentication or the handshake were never finished.
Could you please help me understand if something is wrong with my
configuration or clarify this authentication/handshake process and what
may be wrong?
Thank you,
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Sex, 2013-05-17 at 15:24 +0100, Gordon Sim wrote:
> > I'm using PLAIN in the domain configuration. I was debugging the
> > creation of the messages in the source broker and notice that the
> > qpid::broker::amqp::SaslClient::getVersion calls the
> > Connection::getVersion method which creates a ProtocolVersion(1,0),
> > leaving the protocol field of ProtocolVersion set to 0. Can this be a
> > problem?
>
> Yes!
>
> > After change that to ProtocolVersion(1,0,3) the destination
> > broker no longer complains about SASL layer.
>
> Great... and does it then work?
No, the source broker throws an exception on qpid::CyrusSasl::start
+311. In debug mode, I inspected some variables and it seams that
something is missing, I was expecting to see username and password in
conn p.e but it's not set.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/17/2013 02:39 PM, Bruno Matos wrote:
> On Sex, 2013-05-17 at 13:10 +0100, Gordon Sim wrote:
>> On 05/17/2013 10:37 AM, Bruno Matos wrote:
>>> Now I'm testing with authentication and I'm receiving the message 'SASL
>>> layer required!'. I'm using --auth yes on both brokers with PLAIN
>>> mechanism configured. I'm searching for the code where the mechanisms
>>> are set for the outgoing message, as soon as I found something, I let
>>> you know.
>>
>> That sounds like you are still using NONE. The mechanisms to use are
>> configured as part of the domain object.
>
> I'm using PLAIN in the domain configuration. I was debugging the
> creation of the messages in the source broker and notice that the
> qpid::broker::amqp::SaslClient::getVersion calls the
> Connection::getVersion method which creates a ProtocolVersion(1,0),
> leaving the protocol field of ProtocolVersion set to 0. Can this be a
> problem?
Yes!
> After change that to ProtocolVersion(1,0,3) the destination
> broker no longer complains about SASL layer.
Great... and does it then work?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Sex, 2013-05-17 at 13:10 +0100, Gordon Sim wrote:
> On 05/17/2013 10:37 AM, Bruno Matos wrote:
> > Now I'm testing with authentication and I'm receiving the message 'SASL
> > layer required!'. I'm using --auth yes on both brokers with PLAIN
> > mechanism configured. I'm searching for the code where the mechanisms
> > are set for the outgoing message, as soon as I found something, I let
> > you know.
>
> That sounds like you are still using NONE. The mechanisms to use are
> configured as part of the domain object.
I'm using PLAIN in the domain configuration. I was debugging the
creation of the messages in the source broker and notice that the
qpid::broker::amqp::SaslClient::getVersion calls the
Connection::getVersion method which creates a ProtocolVersion(1,0),
leaving the protocol field of ProtocolVersion set to 0. Can this be a
problem? After change that to ProtocolVersion(1,0,3) the destination
broker no longer complains about SASL layer.
Thank you,
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/17/2013 10:37 AM, Bruno Matos wrote:
> Now I'm testing with authentication and I'm receiving the message 'SASL
> layer required!'. I'm using --auth yes on both brokers with PLAIN
> mechanism configured. I'm searching for the code where the mechanisms
> are set for the outgoing message, as soon as I found something, I let
> you know.
That sounds like you are still using NONE. The mechanisms to use are
configured as part of the domain object.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-16 at 14:26 +0100, Gordon Sim wrote:
> On 05/16/2013 10:07 AM, Bruno Matos wrote:
> > It seams that if some message passes through the link before the
> > --max-negotiate-time the problem disappear. I think its because
> > AsynchIOHandler::readbuff only cancels the timer after 3 reads (as
> > stated in the code) and the interlink doesn't seam to need all the
> > handshake described.
>
> Yes, AMQP 1.0 doesn't force a sequential handshake and for NONE or even
> ANONYMOUS, there is no need for either side to wait for the other in
> order to complete the connection setup.
>
> The max-negotiate-time "feature" is a horrible hack.
>
> Either it needs to be reimplemented or it needs to be disabled (whether
> on a per-connection, per-protocol or per-broker level). For now the
> workaround is to 'disable' it simply by setting the value high enough
> that sufficient traffic occurs (that likely limits its usefulness for
> the problem it was intended to solve of course).
>
> I've raised a JIRA: https://issues.apache.org/jira/browse/QPID-4854
Now I'm testing with authentication and I'm receiving the message 'SASL
layer required!'. I'm using --auth yes on both brokers with PLAIN
mechanism configured. I'm searching for the code where the mechanisms
are set for the outgoing message, as soon as I found something, I let
you know.
Thank you,
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/16/2013 10:07 AM, Bruno Matos wrote:
> It seams that if some message passes through the link before the
> --max-negotiate-time the problem disappear. I think its because
> AsynchIOHandler::readbuff only cancels the timer after 3 reads (as
> stated in the code) and the interlink doesn't seam to need all the
> handshake described.
Yes, AMQP 1.0 doesn't force a sequential handshake and for NONE or even
ANONYMOUS, there is no need for either side to wait for the other in
order to complete the connection setup.
The max-negotiate-time "feature" is a horrible hack.
Either it needs to be reimplemented or it needs to be disabled (whether
on a per-connection, per-protocol or per-broker level). For now the
workaround is to 'disable' it simply by setting the value high enough
that sufficient traffic occurs (that likely limits its usefulness for
the problem it was intended to solve of course).
I've raised a JIRA: https://issues.apache.org/jira/browse/QPID-4854
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qua, 2013-05-15 at 17:01 +0100, Bruno Matos wrote:
> On Ter, 2013-05-14 at 14:32 +0100, Gordon Sim wrote:
> > On 05/14/2013 02:03 PM, Bruno Matos wrote:
> > > I don't understand the use of NONE vs ANONYMOUS, sometimes they seam
> > > exchangeable... I saw ANONYMOUS in the Domain initialization of
> > > mechanisms internal variable either.
> >
> > IN AMQP 1.0 a SASL negotiation is optional. The NONE option for the
> > mechanism is a way to indicate you want to use AMQP 1.0 without any SASL
> > at all. The ANONYMOUS mechanism involves an actual SASL handshake even
> > though it doesn't actually do any authentication. Does that make any sense?
>
> Yes, it makes sense.
> I think I found a clue, I was creating the domain with the property
> 'mechanisms' but the Domain constructor expects 'sasl_mechanisms'. This
> means that domain was thinking it should use ANONYMOUS which leads to
> the selection of the SaslClient as the codec and not the Wrapper.
>
> But the problem persists, and as I saw some places in code that uses
> only 'mechanisms' I changed the 'sasl_mechanisms' definition to
> 'mechanisms' but I still receive 'No protocol received closing' on the
> destination broker. There are more messages going from source broker to
> destination broker now, but it seams that something is still missing.
>
It seams that if some message passes through the link before the
--max-negotiate-time the problem disappear. I think its because
AsynchIOHandler::readbuff only cancels the timer after 3 reads (as
stated in the code) and the interlink doesn't seam to need all the
handshake described.
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Ter, 2013-05-14 at 14:32 +0100, Gordon Sim wrote:
> On 05/14/2013 02:03 PM, Bruno Matos wrote:
> > I don't understand the use of NONE vs ANONYMOUS, sometimes they seam
> > exchangeable... I saw ANONYMOUS in the Domain initialization of
> > mechanisms internal variable either.
>
> IN AMQP 1.0 a SASL negotiation is optional. The NONE option for the
> mechanism is a way to indicate you want to use AMQP 1.0 without any SASL
> at all. The ANONYMOUS mechanism involves an actual SASL handshake even
> though it doesn't actually do any authentication. Does that make any sense?
Yes, it makes sense.
I think I found a clue, I was creating the domain with the property
'mechanisms' but the Domain constructor expects 'sasl_mechanisms'. This
means that domain was thinking it should use ANONYMOUS which leads to
the selection of the SaslClient as the codec and not the Wrapper.
But the problem persists, and as I saw some places in code that uses
only 'mechanisms' I changed the 'sasl_mechanisms' definition to
'mechanisms' but I still receive 'No protocol received closing' on the
destination broker. There are more messages going from source broker to
destination broker now, but it seams that something is still missing.
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/14/2013 02:03 PM, Bruno Matos wrote:
> I don't understand the use of NONE vs ANONYMOUS, sometimes they seam
> exchangeable... I saw ANONYMOUS in the Domain initialization of
> mechanisms internal variable either.
IN AMQP 1.0 a SASL negotiation is optional. The NONE option for the
mechanism is a way to indicate you want to use AMQP 1.0 without any SASL
at all. The ANONYMOUS mechanism involves an actual SASL handshake even
though it doesn't actually do any authentication. Does that make any sense?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Ter, 2013-05-14 at 11:49 +0100, Gordon Sim wrote:
> On 05/14/2013 11:40 AM, Bruno Matos wrote:
> >> Is that the case even when you have NONE selected for the
> >> sasl_mechanisms in the link? There does seem to be an issue with
> >> interbroker SASL which I am investigating.
> >>
> >
> > Yes.
> > I'm trying to do some debugging myself, not that I have the knowledge,
> > but if I find something 'strange' I'll let you know.
>
> You can turn on some protocol logging with --log-enable trace:Protocol
> (note however that the actual output comes from the proton lib and that
> doesn't yet honour any output to file or syslog options (i.e. it just
> goes to the console).
>
> If you want to send me the output I can also take a look.
>
I send the output from the se source broker in attachment, the output of
the destination broker was only
<- AMQP
-> AMQP
I don't understand the use of NONE vs ANONYMOUS, sometimes they seam
exchangeable... I saw ANONYMOUS in the Domain initialization of
mechanisms internal variable either.
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/14/2013 11:40 AM, Bruno Matos wrote:
> On Ter, 2013-05-14 at 09:48 +0100, Gordon Sim wrote:
>> On 05/13/2013 02:31 PM, Bruno Matos wrote:
>>> Now all tests pass,
>>> but the problem is still there, if I don't set the --max-negotiate-time,
>>> 10 seconds after the outgoing link creation, the destination broker
>>> gives 'error Connection qpid.192.168.102.104:5672-192.168.102.7:52067 No
>>> protocol received closing' and it's deleted in the source broker.
>>
>> Is that the case even when you have NONE selected for the
>> sasl_mechanisms in the link? There does seem to be an issue with
>> interbroker SASL which I am investigating.
>>
>
> Yes.
> I'm trying to do some debugging myself, not that I have the knowledge,
> but if I find something 'strange' I'll let you know.
You can turn on some protocol logging with --log-enable trace:Protocol
(note however that the actual output comes from the proton lib and that
doesn't yet honour any output to file or syslog options (i.e. it just
goes to the console).
If you want to send me the output I can also take a look.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Ter, 2013-05-14 at 09:48 +0100, Gordon Sim wrote:
> On 05/13/2013 02:31 PM, Bruno Matos wrote:
> > Now all tests pass,
> > but the problem is still there, if I don't set the --max-negotiate-time,
> > 10 seconds after the outgoing link creation, the destination broker
> > gives 'error Connection qpid.192.168.102.104:5672-192.168.102.7:52067 No
> > protocol received closing' and it's deleted in the source broker.
>
> Is that the case even when you have NONE selected for the
> sasl_mechanisms in the link? There does seem to be an issue with
> interbroker SASL which I am investigating.
>
Yes.
I'm trying to do some debugging myself, not that I have the knowledge,
but if I find something 'strange' I'll let you know.
Thank you.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/13/2013 02:31 PM, Bruno Matos wrote:
> Now all tests pass,
> but the problem is still there, if I don't set the --max-negotiate-time,
> 10 seconds after the outgoing link creation, the destination broker
> gives 'error Connection qpid.192.168.102.104:5672-192.168.102.7:52067 No
> protocol received closing' and it's deleted in the source broker.
Is that the case even when you have NONE selected for the
sasl_mechanisms in the link? There does seem to be an issue with
interbroker SASL which I am investigating.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Seg, 2013-05-13 at 12:17 +0100, Gordon Sim wrote:
> On 05/13/2013 11:59 AM, Bruno Matos wrote:
> > On Qui, 2013-05-09 at 16:02 +0100, Gordon Sim wrote:
> >> On 05/09/2013 03:13 PM, Bruno Matos wrote:
> >>> The same, after 10 minutes it gives:
> >>> error Connection qpid.192.168.102.104:5672-192.168.102.7:50729 No
> >>> protocol received closing
> >>>
> >>> Be aware that this is a local compilation with no install, something can
> >>> be wrong with modules or something else, not that I have notice, but it
> >>> can.
> >>
> >> Hmm... did you use autotools or cmake? If you run: make check
> >> TESTS=run_interlink_tests (if using autotools) or ctest -R interlink (if
> >> using cmake) do the tests all pass?
> >
> > I'm using cmake, and the interlink tests failed indeed, I'll try to
> > understand why, and I'll let you know.
> >
> > They failed on SL6.3, but they pass on FC18.
>
> Is it the same version of proton in each case? Do they all fail or just
> some of them?
Sorry to waste your time, it was my fault, as expected... One had an old
qpid version that was conflicting with the new one and the other didn't
have qpid libraries in the python's library path. Now all tests pass,
but the problem is still there, if I don't set the --max-negotiate-time,
10 seconds after the outgoing link creation, the destination broker
gives 'error Connection qpid.192.168.102.104:5672-192.168.102.7:52067 No
protocol received closing' and it's deleted in the source broker.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/13/2013 11:59 AM, Bruno Matos wrote:
> On Qui, 2013-05-09 at 16:02 +0100, Gordon Sim wrote:
>> On 05/09/2013 03:13 PM, Bruno Matos wrote:
>>> The same, after 10 minutes it gives:
>>> error Connection qpid.192.168.102.104:5672-192.168.102.7:50729 No
>>> protocol received closing
>>>
>>> Be aware that this is a local compilation with no install, something can
>>> be wrong with modules or something else, not that I have notice, but it
>>> can.
>>
>> Hmm... did you use autotools or cmake? If you run: make check
>> TESTS=run_interlink_tests (if using autotools) or ctest -R interlink (if
>> using cmake) do the tests all pass?
>
> I'm using cmake, and the interlink tests failed indeed, I'll try to
> understand why, and I'll let you know.
>
> They failed on SL6.3, but they pass on FC18.
Is it the same version of proton in each case? Do they all fail or just
some of them?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-09 at 16:02 +0100, Gordon Sim wrote:
> On 05/09/2013 03:13 PM, Bruno Matos wrote:
> > The same, after 10 minutes it gives:
> > error Connection qpid.192.168.102.104:5672-192.168.102.7:50729 No
> > protocol received closing
> >
> > Be aware that this is a local compilation with no install, something can
> > be wrong with modules or something else, not that I have notice, but it
> > can.
>
> Hmm... did you use autotools or cmake? If you run: make check
> TESTS=run_interlink_tests (if using autotools) or ctest -R interlink (if
> using cmake) do the tests all pass?
I'm using cmake, and the interlink tests failed indeed, I'll try to
understand why, and I'll let you know.
They failed on SL6.3, but they pass on FC18.
Thank you.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/09/2013 03:13 PM, Bruno Matos wrote:
> The same, after 10 minutes it gives:
> error Connection qpid.192.168.102.104:5672-192.168.102.7:50729 No
> protocol received closing
>
> Be aware that this is a local compilation with no install, something can
> be wrong with modules or something else, not that I have notice, but it
> can.
Hmm... did you use autotools or cmake? If you run: make check
TESTS=run_interlink_tests (if using autotools) or ctest -R interlink (if
using cmake) do the tests all pass?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-09 at 14:48 +0100, Gordon Sim wrote:
> On 05/09/2013 02:45 PM, Bruno Matos wrote:
> > On Qui, 2013-05-09 at 14:33 +0100, Bruno Matos wrote:
> >> On Qui, 2013-05-09 at 14:02 +0100, Gordon Sim wrote:
> >>> On 05/09/2013 01:52 PM, Bruno Matos wrote:
> >>>> Finally I have some time to test domains.
> >>>
> >>> Excellent, thanks!
> >>>
> >>>> I'm trying to create a link between two Brokers 0.22 RC2, but I'm having
> >>>> two errors, with the same origin, creating the outgoing link that I
> >>>> don't know how to solve. I'm using qpid-ctrl as you suggested.
> >>>>
> >>>> 1. If I set --auth yes (on both), I receive the error "SASL layer
> >>>> required!", I took a look to the code and it seams the it was expecting
> >>>> SASL as the protocol and it has AMQP.
> >>>
> >>> Was this from the connection made by qpid-ctrl itself, or the
> >>> inter-broker connection? If auth is on then the broker will not accept a
> >>> connection that does not have a sasl layer setup first. You can specify
> >>> the mechanism(s) to use for the inter-broker link (NONE means no SASL
> >>> layer, which would not work if the remote broker requires SASL as is the
> >>> case for qpidd with auth = true)
> >>
> >> It was from the inter-broker connection. I will reproduce the last try:
> >>
> >> I have two brokers, b1 and b2 with --auth yes on different machines, I
> >> run the following on b1's machine:
> >>
> >> 1. qpid-ctrl create type=domain name=my-domain
> >> properties="{'url':'b2','mechanisms':'PLAIN'}"
> >>
> >> b1 logs:
> >>
> >> notice Created domain my-domain with url amqp:tcp:b2:5672 from
> >> {mechanisms:PLAIN, url:b2}
> >>
> >> b2 logs:
> >>
> >> -- empty --
> >>
> >>
> >> 2. ./qpid-ctrl create type=outgoing name=my-outgoing-link
> >> properties="{'domain':'my-domain','source':'amq.topic','target':'amq.topic'}"
> >>
> >> b1 logs:
> >> notice Creating interconnect my-outgoing-link, {domain:my-domain,
> >> source:amq.topic, target:amq.topic}
> >> notice Interconnect deleted
> >>
> >> b2 logs:
> >> error SASL layer required!
> >>
> >>>
> >>>> 2. If I set --auth no (on both), the connection closes by timeout (10s)
> >>>> on the destination broker and it gives "No protocol received closing",
> >>>> which produces a "Interconnect deleted" notice on the source broker.
> >>>
> >>> This is due to a 'feature' in the broker intended to prevent idle
> >>> connections prior to authentication. The problem is that it does this in
> >>> a very crude way, merely counting the number of distinct read operations
> >>> from the socket and requiring there to be 3 in a given time.
> >>>
> >>> If you set a larger --max-negotiate-time you can avoid this (e.g. 600000).
> >>
> >> Now the error message doesn't show up, but I send a message to b1 with a
> >> subject binded by a queue on b2 and no messages are received in that
> >> queue.
> >
> > Update: the error message does show up after 10 min, as defined.
>
> Try with auth=no and mechanisms:NONE... I'll look into the SASL issue
> and get back to you.
>
The same, after 10 minutes it gives:
error Connection qpid.192.168.102.104:5672-192.168.102.7:50729 No
protocol received closing
Be aware that this is a local compilation with no install, something can
be wrong with modules or something else, not that I have notice, but it
can.
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/09/2013 02:45 PM, Bruno Matos wrote:
> On Qui, 2013-05-09 at 14:33 +0100, Bruno Matos wrote:
>> On Qui, 2013-05-09 at 14:02 +0100, Gordon Sim wrote:
>>> On 05/09/2013 01:52 PM, Bruno Matos wrote:
>>>> Finally I have some time to test domains.
>>>
>>> Excellent, thanks!
>>>
>>>> I'm trying to create a link between two Brokers 0.22 RC2, but I'm having
>>>> two errors, with the same origin, creating the outgoing link that I
>>>> don't know how to solve. I'm using qpid-ctrl as you suggested.
>>>>
>>>> 1. If I set --auth yes (on both), I receive the error "SASL layer
>>>> required!", I took a look to the code and it seams the it was expecting
>>>> SASL as the protocol and it has AMQP.
>>>
>>> Was this from the connection made by qpid-ctrl itself, or the
>>> inter-broker connection? If auth is on then the broker will not accept a
>>> connection that does not have a sasl layer setup first. You can specify
>>> the mechanism(s) to use for the inter-broker link (NONE means no SASL
>>> layer, which would not work if the remote broker requires SASL as is the
>>> case for qpidd with auth = true)
>>
>> It was from the inter-broker connection. I will reproduce the last try:
>>
>> I have two brokers, b1 and b2 with --auth yes on different machines, I
>> run the following on b1's machine:
>>
>> 1. qpid-ctrl create type=domain name=my-domain
>> properties="{'url':'b2','mechanisms':'PLAIN'}"
>>
>> b1 logs:
>>
>> notice Created domain my-domain with url amqp:tcp:b2:5672 from
>> {mechanisms:PLAIN, url:b2}
>>
>> b2 logs:
>>
>> -- empty --
>>
>>
>> 2. ./qpid-ctrl create type=outgoing name=my-outgoing-link
>> properties="{'domain':'my-domain','source':'amq.topic','target':'amq.topic'}"
>>
>> b1 logs:
>> notice Creating interconnect my-outgoing-link, {domain:my-domain,
>> source:amq.topic, target:amq.topic}
>> notice Interconnect deleted
>>
>> b2 logs:
>> error SASL layer required!
>>
>>>
>>>> 2. If I set --auth no (on both), the connection closes by timeout (10s)
>>>> on the destination broker and it gives "No protocol received closing",
>>>> which produces a "Interconnect deleted" notice on the source broker.
>>>
>>> This is due to a 'feature' in the broker intended to prevent idle
>>> connections prior to authentication. The problem is that it does this in
>>> a very crude way, merely counting the number of distinct read operations
>>> from the socket and requiring there to be 3 in a given time.
>>>
>>> If you set a larger --max-negotiate-time you can avoid this (e.g. 600000).
>>
>> Now the error message doesn't show up, but I send a message to b1 with a
>> subject binded by a queue on b2 and no messages are received in that
>> queue.
>
> Update: the error message does show up after 10 min, as defined.
Try with auth=no and mechanisms:NONE... I'll look into the SASL issue
and get back to you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-09 at 14:33 +0100, Bruno Matos wrote:
> On Qui, 2013-05-09 at 14:02 +0100, Gordon Sim wrote:
> > On 05/09/2013 01:52 PM, Bruno Matos wrote:
> > > Finally I have some time to test domains.
> >
> > Excellent, thanks!
> >
> > > I'm trying to create a link between two Brokers 0.22 RC2, but I'm having
> > > two errors, with the same origin, creating the outgoing link that I
> > > don't know how to solve. I'm using qpid-ctrl as you suggested.
> > >
> > > 1. If I set --auth yes (on both), I receive the error "SASL layer
> > > required!", I took a look to the code and it seams the it was expecting
> > > SASL as the protocol and it has AMQP.
> >
> > Was this from the connection made by qpid-ctrl itself, or the
> > inter-broker connection? If auth is on then the broker will not accept a
> > connection that does not have a sasl layer setup first. You can specify
> > the mechanism(s) to use for the inter-broker link (NONE means no SASL
> > layer, which would not work if the remote broker requires SASL as is the
> > case for qpidd with auth = true)
>
> It was from the inter-broker connection. I will reproduce the last try:
>
> I have two brokers, b1 and b2 with --auth yes on different machines, I
> run the following on b1's machine:
>
> 1. qpid-ctrl create type=domain name=my-domain
> properties="{'url':'b2','mechanisms':'PLAIN'}"
>
> b1 logs:
>
> notice Created domain my-domain with url amqp:tcp:b2:5672 from
> {mechanisms:PLAIN, url:b2}
>
> b2 logs:
>
> -- empty --
>
>
> 2. ./qpid-ctrl create type=outgoing name=my-outgoing-link
> properties="{'domain':'my-domain','source':'amq.topic','target':'amq.topic'}"
>
> b1 logs:
> notice Creating interconnect my-outgoing-link, {domain:my-domain,
> source:amq.topic, target:amq.topic}
> notice Interconnect deleted
>
> b2 logs:
> error SASL layer required!
>
> >
> > > 2. If I set --auth no (on both), the connection closes by timeout (10s)
> > > on the destination broker and it gives "No protocol received closing",
> > > which produces a "Interconnect deleted" notice on the source broker.
> >
> > This is due to a 'feature' in the broker intended to prevent idle
> > connections prior to authentication. The problem is that it does this in
> > a very crude way, merely counting the number of distinct read operations
> > from the socket and requiring there to be 3 in a given time.
> >
> > If you set a larger --max-negotiate-time you can avoid this (e.g. 600000).
>
> Now the error message doesn't show up, but I send a message to b1 with a
> subject binded by a queue on b2 and no messages are received in that
> queue.
Update: the error message does show up after 10 min, as defined.
>
> >
> > Do let me know how you get on (especially if this doesn't help :-)
>
> Thank you very much for your time,
> Regards.
>
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Bruno Matos <br...@paradigmaxis.pt>.
On Qui, 2013-05-09 at 14:02 +0100, Gordon Sim wrote:
> On 05/09/2013 01:52 PM, Bruno Matos wrote:
> > Finally I have some time to test domains.
>
> Excellent, thanks!
>
> > I'm trying to create a link between two Brokers 0.22 RC2, but I'm having
> > two errors, with the same origin, creating the outgoing link that I
> > don't know how to solve. I'm using qpid-ctrl as you suggested.
> >
> > 1. If I set --auth yes (on both), I receive the error "SASL layer
> > required!", I took a look to the code and it seams the it was expecting
> > SASL as the protocol and it has AMQP.
>
> Was this from the connection made by qpid-ctrl itself, or the
> inter-broker connection? If auth is on then the broker will not accept a
> connection that does not have a sasl layer setup first. You can specify
> the mechanism(s) to use for the inter-broker link (NONE means no SASL
> layer, which would not work if the remote broker requires SASL as is the
> case for qpidd with auth = true)
It was from the inter-broker connection. I will reproduce the last try:
I have two brokers, b1 and b2 with --auth yes on different machines, I
run the following on b1's machine:
1. qpid-ctrl create type=domain name=my-domain
properties="{'url':'b2','mechanisms':'PLAIN'}"
b1 logs:
notice Created domain my-domain with url amqp:tcp:b2:5672 from
{mechanisms:PLAIN, url:b2}
b2 logs:
-- empty --
2. ./qpid-ctrl create type=outgoing name=my-outgoing-link
properties="{'domain':'my-domain','source':'amq.topic','target':'amq.topic'}"
b1 logs:
notice Creating interconnect my-outgoing-link, {domain:my-domain,
source:amq.topic, target:amq.topic}
notice Interconnect deleted
b2 logs:
error SASL layer required!
>
> > 2. If I set --auth no (on both), the connection closes by timeout (10s)
> > on the destination broker and it gives "No protocol received closing",
> > which produces a "Interconnect deleted" notice on the source broker.
>
> This is due to a 'feature' in the broker intended to prevent idle
> connections prior to authentication. The problem is that it does this in
> a very crude way, merely counting the number of distinct read operations
> from the socket and requiring there to be 3 in a given time.
>
> If you set a larger --max-negotiate-time you can avoid this (e.g. 600000).
Now the error message doesn't show up, but I send a message to b1 with a
subject binded by a queue on b2 and no messages are received in that
queue.
>
> Do let me know how you get on (especially if this doesn't help :-)
Thank you very much for your time,
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Posted by Gordon Sim <gs...@redhat.com>.
On 05/09/2013 01:52 PM, Bruno Matos wrote:
> Finally I have some time to test domains.
Excellent, thanks!
> I'm trying to create a link between two Brokers 0.22 RC2, but I'm having
> two errors, with the same origin, creating the outgoing link that I
> don't know how to solve. I'm using qpid-ctrl as you suggested.
>
> 1. If I set --auth yes (on both), I receive the error "SASL layer
> required!", I took a look to the code and it seams the it was expecting
> SASL as the protocol and it has AMQP.
Was this from the connection made by qpid-ctrl itself, or the
inter-broker connection? If auth is on then the broker will not accept a
connection that does not have a sasl layer setup first. You can specify
the mechanism(s) to use for the inter-broker link (NONE means no SASL
layer, which would not work if the remote broker requires SASL as is the
case for qpidd with auth = true)
> 2. If I set --auth no (on both), the connection closes by timeout (10s)
> on the destination broker and it gives "No protocol received closing",
> which produces a "Interconnect deleted" notice on the source broker.
This is due to a 'feature' in the broker intended to prevent idle
connections prior to authentication. The problem is that it does this in
a very crude way, merely counting the number of distinct read operations
from the socket and requiring there to be 3 in a given time.
If you set a larger --max-negotiate-time you can avoid this (e.g. 600000).
Do let me know how you get on (especially if this doesn't help :-)
--Gordon.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org