[c++]: Progressing AMQP 1.0 support for 0.22 release

[Gordon Sim <gs...@redhat.com>]

I hope to make some further progress with AMQP 1.0 support for the next 
release. Some of the gaps remaining are:

* inter-broker links

This allows qpidd to be hooked into wider 1.0 based networks which 
expands the options for building or evolving systems.

* lifetime policy for nodes created on link establishment

I.e. the 1.0 equivalents for auto-delete. This is important for the many 
applications that use temporary reply queues etc. I think the 1.0 
defined behaviour will also be more intuitive and useful and may involve 
some suggestions around improvements to the addressing options.

* automatic failover and message replay for qpid::messaging

One question here is likely to be around the division of work between 
proton's protocol engine and the qpid::messaging implementation. (E.g. 
The former already holds a buffer of outgoing messages, can this be used 
or will the client need to duplicate that work).

* support for the assert option

I.e. the ability to specify the node properties and/or capabilities that 
are assumed and to raise an error if these are not in fact met.

* transaction support in both qpid::messaging and qpidd

There is not a great deal of time left in the 0.22 release cycle and I'm 
certainly not going to get all of these done in time for that. My 
current plan is to work through them in the order I've listed them here. 
I also want to focus on getting a set of 1.0 based tests for various 
aspects of qpidd functionality that can be used to test & explore 
interoperability with any other broker.

I'd be delighted to hear from anyone with thoughts on any or all aspects 
of this (or indeed on points relating to 1.0 support that I have not 
considered). If you have a different view of what the priorities should 
be, lets debate it further. I'd be especially eager to hear from anyone 
planning to use 1.0 (or anyone using the 'assert' option in addresses, 
is it useful in practice?).

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

[Bruno Matos <br...@paradigmaxis.pt>]

On Ter, 2013-02-05 at 11:54 +0000, Gordon Sim wrote:
> On 02/05/2013 10:46 AM, Bruno Matos wrote:
> > Hi Gordon,
> >
> > On Seg, 2013-02-04 at 16:11 +0000, Gordon Sim wrote:
> >> On 02/04/2013 02:59 PM, Bruno Matos wrote:
> >>> Hi Gordon,
> >>>
> >>> * support for the assert option
> >>>
> >>> This support includes disable all assertions, including the existence of
> >>> the endpoint, as we discussed some time ago?
> >>
> >> Good question! Though in 1.0 the situation is somewhat different from
> >> 0-10[1], calls to createSender()/createReceiver() do still block until a
> >> response has been received from the server allowing validation of the
> >> target or source.
> >>
> >> That is certainly something that can be relaxed. However I'm not
> >> convinced that the assert option is the right mechanism. I think the
> >> most direct and clear way of offering users the choice there would be to
> >> overload the methods with variants that took a sync flag (much like with
> >> send() and acknowledge()). What do you think?
> >
> > Would be something like 'session.createSender(address, dontVerify)' ?
> 
> I would call the second parameter 'sync' I think, it would be a boolean 
> which when true would give the current synchronous behaviour, i.e. the 
> call would block until the server responded (and would then throw an 
> error if the server indicated there was no such node or its properties 
> were not as requested, or permission was denied etc). If the value was 
> false then the call would return as soon as the request had been issued 
> and return from the method would not guarantee that the sender/receiver 
> was actually linked to a valid node.

It may not be obvious that an async call will ignore the validations.
But for me it's just fine.

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

[Gordon Sim <gs...@redhat.com>]

On 02/05/2013 10:46 AM, Bruno Matos wrote:
> Hi Gordon,
>
> On Seg, 2013-02-04 at 16:11 +0000, Gordon Sim wrote:
>> On 02/04/2013 02:59 PM, Bruno Matos wrote:
>>> Hi Gordon,
>>>
>>> * support for the assert option
>>>
>>> This support includes disable all assertions, including the existence of
>>> the endpoint, as we discussed some time ago?
>>
>> Good question! Though in 1.0 the situation is somewhat different from
>> 0-10[1], calls to createSender()/createReceiver() do still block until a
>> response has been received from the server allowing validation of the
>> target or source.
>>
>> That is certainly something that can be relaxed. However I'm not
>> convinced that the assert option is the right mechanism. I think the
>> most direct and clear way of offering users the choice there would be to
>> overload the methods with variants that took a sync flag (much like with
>> send() and acknowledge()). What do you think?
>
> Would be something like 'session.createSender(address, dontVerify)' ?

I would call the second parameter 'sync' I think, it would be a boolean 
which when true would give the current synchronous behaviour, i.e. the 
call would block until the server responded (and would then throw an 
error if the server indicated there was no such node or its properties 
were not as requested, or permission was denied etc). If the value was 
false then the call would return as soon as the request had been issued 
and return from the method would not guarantee that the sender/receiver 
was actually linked to a valid node.

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

[Bruno Matos <br...@paradigmaxis.pt>]

Hi Gordon,

On Seg, 2013-02-04 at 16:11 +0000, Gordon Sim wrote:
> On 02/04/2013 02:59 PM, Bruno Matos wrote:
> > Hi Gordon,
> >
> > * support for the assert option
> >
> > This support includes disable all assertions, including the existence of
> > the endpoint, as we discussed some time ago?
> 
> Good question! Though in 1.0 the situation is somewhat different from 
> 0-10[1], calls to createSender()/createReceiver() do still block until a 
> response has been received from the server allowing validation of the 
> target or source.
> 
> That is certainly something that can be relaxed. However I'm not 
> convinced that the assert option is the right mechanism. I think the 
> most direct and clear way of offering users the choice there would be to 
> overload the methods with variants that took a sync flag (much like with 
> send() and acknowledge()). What do you think?

Would be something like 'session.createSender(address, dontVerify)' ?

> 
> I'd be happy to add that to my list. Do we have a JIRA for it already do 
> you remember?

I don't remember, but I took a look at the mail thread and did a search
in JIRA and I didn't find anything.

> 
> --Gordon
> 
> [1] In 0-10 there is a synchronous queue- or exchange- declare issued 
> when creating a sender or receiver. Since 0-10 only allows messages to 
> be sent to an exchange, messages actually intended for queues that don't 
> exist are simply dropped. The declare was mainly motivated by the desire 
> to make that situation more explicit. There is of course also a 
> 'resolution' of the node, i.e. a query (an exchange-bound command to be 
> precise) to determine whether the node is a queue or an exchange. This 
> stage is also synchronous but can be disabled by explicitly identifying 
> the type in the address.
> 
> In 1.0 all that is needed is an attach notification by the client which 
> is then echoed by the broker. Messages can only be sent on an attached 
> link and the clients needn't actually know anything about the node type 
> (unless of course they want to verify certain capabilities).
> 

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

[Gordon Sim <gs...@redhat.com>]

On 02/04/2013 02:59 PM, Bruno Matos wrote:
> Hi Gordon,
>
> * support for the assert option
>
> This support includes disable all assertions, including the existence of
> the endpoint, as we discussed some time ago?

Good question! Though in 1.0 the situation is somewhat different from 
0-10[1], calls to createSender()/createReceiver() do still block until a 
response has been received from the server allowing validation of the 
target or source.

That is certainly something that can be relaxed. However I'm not 
convinced that the assert option is the right mechanism. I think the 
most direct and clear way of offering users the choice there would be to 
overload the methods with variants that took a sync flag (much like with 
send() and acknowledge()). What do you think?

I'd be happy to add that to my list. Do we have a JIRA for it already do 
you remember?

--Gordon

[1] In 0-10 there is a synchronous queue- or exchange- declare issued 
when creating a sender or receiver. Since 0-10 only allows messages to 
be sent to an exchange, messages actually intended for queues that don't 
exist are simply dropped. The declare was mainly motivated by the desire 
to make that situation more explicit. There is of course also a 
'resolution' of the node, i.e. a query (an exchange-bound command to be 
precise) to determine whether the node is a queue or an exchange. This 
stage is also synchronous but can be disabled by explicitly identifying 
the type in the address.

In 1.0 all that is needed is an attach notification by the client which 
is then echoed by the broker. Messages can only be sent on an attached 
link and the clients needn't actually know anything about the node type 
(unless of course they want to verify certain capabilities).


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

[Bruno Matos <br...@paradigmaxis.pt>]

Hi Gordon,

* support for the assert option 

This support includes disable all assertions, including the existence of
the endpoint, as we discussed some time ago?

Thank you,
Regards.

On Seg, 2013-02-04 at 13:53 +0000, Gordon Sim wrote:
> I hope to make some further progress with AMQP 1.0 support for the next 
> release. Some of the gaps remaining are:
> 
> * inter-broker links
> 
> This allows qpidd to be hooked into wider 1.0 based networks which 
> expands the options for building or evolving systems.
> 
> * lifetime policy for nodes created on link establishment
> 
> I.e. the 1.0 equivalents for auto-delete. This is important for the many 
> applications that use temporary reply queues etc. I think the 1.0 
> defined behaviour will also be more intuitive and useful and may involve 
> some suggestions around improvements to the addressing options.
> 
> * automatic failover and message replay for qpid::messaging
> 
> One question here is likely to be around the division of work between 
> proton's protocol engine and the qpid::messaging implementation. (E.g. 
> The former already holds a buffer of outgoing messages, can this be used 
> or will the client need to duplicate that work).
> 
> * support for the assert option
> 
> I.e. the ability to specify the node properties and/or capabilities that 
> are assumed and to raise an error if these are not in fact met.
> 
> * transaction support in both qpid::messaging and qpidd
> 
> There is not a great deal of time left in the 0.22 release cycle and I'm 
> certainly not going to get all of these done in time for that. My 
> current plan is to work through them in the order I've listed them here. 
> I also want to focus on getting a set of 1.0 based tests for various 
> aspects of qpidd functionality that can be used to test & explore 
> interoperability with any other broker.
> 
> I'd be delighted to hear from anyone with thoughts on any or all aspects 
> of this (or indeed on points relating to 1.0 support that I have not 
> considered). If you have a different view of what the priorities should 
> be, lets debate it further. I'd be especially eager to hear from anyone 
> planning to use 1.0 (or anyone using the 'assert' option in addresses, 
> is it useful in practice?).
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 

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

[Gordon Sim <gs...@redhat.com>]

On 02/05/2013 10:26 AM, Bruno Matos wrote:
> Hi Gordon,
>
>> Another good question!
>>
>> In establishing a link to another broker, qpidd is not doing anything
>> that other client libraries must be able to do. From the perspective of
>> that other broker qpidd can be treated as just another producer or consumer.
>>
>> However there are aspects that will certainly benefit from more activity
>> in the standards group. The handling of reply-to in networks of
>> different broker implementations is a good example.
>
> Could you explain this? As you might have seen, I'm looking for a
> solution to reply to a queue in a federated broker from a service in the
> main broker. Is this what you are talking about?

Yes. As you've seen we don't yet have a nice, transparent solution even 
between qpidd instances. Adding other implementations into the network 
would only make this worse unless we adopt some standard 
conventions/best practices etc.


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

[Bruno Matos <br...@paradigmaxis.pt>]

Hi Gordon,

> Another good question!
> 
> In establishing a link to another broker, qpidd is not doing anything 
> that other client libraries must be able to do. From the perspective of 
> that other broker qpidd can be treated as just another producer or consumer.
> 
> However there are aspects that will certainly benefit from more activity 
> in the standards group. The handling of reply-to in networks of 
> different broker implementations is a good example.

Could you explain this? As you might have seen, I'm looking for a
solution to reply to a queue in a federated broker from a service in the
main broker. Is this what you are talking about?

> 
> So while I think this work can (and should) get started now, I think it 
> will also ultimately need to be updated to take account of further 
> detail on the syntax and semantics of an 'address-string', any 
> standardisation efforts around management (mechanism and schema) etc.
> 

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

Re: [c++]: Progressing AMQP 1.0 support for 0.22 release

[Bruno Matos <br...@paradigmaxis.pt>]

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

[Gordon Sim <gs...@redhat.com>]

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

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

[Bruno Matos <br...@paradigmaxis.pt>]

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?

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

[Bruno Matos <br...@paradigmaxis.pt>]

On Qui, 2013-03-14 at 13:08 +0000, Gordon Sim wrote:
> On 02/15/2013 06:22 PM, Gordon Sim wrote:
> > 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.
> 
> This is now ready to commit (I have added some automated tests and fixed 
> a few issues that came up). Though the alpha period is now over, I don't 
> see these changes as problematic for the beta. They only affect the 1.0 
> implementation and are optional enhancements to that. The details of the 
> change have been available for review and comment for some time. So, 
> unless anyone objects I'll be committing the update shortly.
> 

I hope you can commit, looking forward to see it in the next version.

> As an additional but separate step I'd like to add some better tooling 
> for this work. There are a couple of different options there. One is to 
> extend the existing qpid-config tool to allow creation of domains and 
> links to other 1.0 enabled entities. The other is to add a new tool for 
> that purpose (this could be quite generic and thus usable for creating, 
> deleting and listing objects of any type). I lean towards the second 
> option. If you have a view on that, let me know.

That would be very useful.

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

[Gordon Sim <gs...@redhat.com>]

On 03/26/2013 05:07 PM, Fraser Adams wrote:
> Hi Gordon,
> I was thinking about this thread earlier on today and something just
> struck me about the general tool "for creating,
> deleting and listing objects of any type" that you attached previously
> and is being discussed here.
>
> I think that the general premise is that it provides a more "general"
> approach than say qpid-config because it's abstracting to the broker
> create and delete methods and given that type, name and other properties
> can be specified as a Map that gives a fair degree of generality - is my
> understanding correct?

Yes. The current qpid-config needs to be updated for every type it can 
create, delete or list though the same basic mechanisms are used in each 
case.

Specific knowledge of types is useful in list as it can allow the exact 
fields displayed and their order to be more tailored. There is also a 
fair amount of option/argument 'munging' in qpid-config (in my view 
slightly less obviously justifiable).

> If it is then the thing that struck me is that there was already a tool
> that provided this sort of behaviour (actually possibly even more
> general) - do you recall qpid-ctrl?

I do indeed! I would see it is almost too general. Though it does allow 
access to all QMF methods (e.g. queue purge etc), it does make using the 
create and delete methods a fraction more complicated. It also doesn't 
support listing objects.

> It's not necessarily in the most helpful location "qpid/cpp/src/tests"
> but it seems pretty similar to what you are describing here unless I've
> misunderstood.

It is similar... my reason for not picking that was that I felt in 
hindsight it wasn't as usable for the cases I really cared about. I 
guess this all goes to emphasise the validity of Ken's point (and indeed 
the theme you have often mentioned) namely some coherent vision for 
management tools.

> I remember qpid-ctrl because I wrote a Java port of it in
> my QMF bundle.

You don't do things by halves! I admire your consistency!

> It's been a little while since I looked at the python
> version, but digging out the JavaDoc I put in my Java one I note:
>
>   * List the properties of the qmf.default.direct exchange:
>   * <pre>QpidCtrl -c exchange -i qmf.default.direct listValues</pre>
>   *
>   * Create a queue called test with a flow-to-disk limit policy:
>   * <pre>QpidCtrl create
> "{type:queue,name:test,properties:{'qpid.policy_type':ring}}"</pre>
>   *
>   * Delete a queue called test:
>   * <pre>QpidCtrl delete "{type:queue,name:test}"</pre>
>   *
>   * Create a binding called bind1 between the amq.match exchange and the
> test queue matching the headers name=fadams
>   * and gender=male:
>   * <pre>QpidCtrl create
> "{type:binding,name:'amq.match/test/bind1',properties:{x-match:all,name:fadams,gender:male}}"</pre>
>
>   *
>   * Delete the binding called bind1 between the amq.match exchange and
> the test queue:
>   * <pre>QpidCtrl delete "{type:binding,name:'amq.match/test/bind1'}"</pre>
>
>
> Apologies if I've misunderstood the context, but I thought it was worth
> mentioning given that the main thrust of conversation was about a
> general way of controlling arbitrary objects.

I think create and delete should really be 'built in' to a management 
mechanism, rather than being schema dependent as they are in QMF for the 
broker(s).


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

[Fraser Adams <fr...@blueyonder.co.uk>]

Hi Gordon,
I was thinking about this thread earlier on today and something just 
struck me about the general tool "for creating,
deleting and listing objects of any type" that you attached previously 
and is being discussed here.

I think that the general premise is that it provides a more "general" 
approach than say qpid-config because it's abstracting to the broker 
create and delete methods and given that type, name and other properties 
can be specified as a Map that gives a fair degree of generality - is my 
understanding correct?

If it is then the thing that struck me is that there was already a tool 
that provided this sort of behaviour (actually possibly even more 
general) - do you recall qpid-ctrl?

It's not necessarily in the most helpful location "qpid/cpp/src/tests" 
but it seems pretty similar to what you are describing here unless I've 
misunderstood. I remember qpid-ctrl because I wrote a Java port of it in 
my QMF bundle. It's been a little while since I looked at the python 
version, but digging out the JavaDoc I put in my Java one I note:

  * List the properties of the qmf.default.direct exchange:
  * <pre>QpidCtrl -c exchange -i qmf.default.direct listValues</pre>
  *
  * Create a queue called test with a flow-to-disk limit policy:
  * <pre>QpidCtrl create 
"{type:queue,name:test,properties:{'qpid.policy_type':ring}}"</pre>
  *
  * Delete a queue called test:
  * <pre>QpidCtrl delete "{type:queue,name:test}"</pre>
  *
  * Create a binding called bind1 between the amq.match exchange and the 
test queue matching the headers name=fadams
  * and gender=male:
  * <pre>QpidCtrl create 
"{type:binding,name:'amq.match/test/bind1',properties:{x-match:all,name:fadams,gender:male}}"</pre>
  *
  * Delete the binding called bind1 between the amq.match exchange and 
the test queue:
  * <pre>QpidCtrl delete "{type:binding,name:'amq.match/test/bind1'}"</pre>


Apologies if I've misunderstood the context, but I thought it was worth 
mentioning given that the main thrust of conversation was about a 
general way of controlling arbitrary objects.

Cheers,
Frase

On 21/03/13 15:47, Gordon Sim wrote:
> On 03/21/2013 01:19 PM, Ken Giusti wrote:
>> Hmmmm... seems like there's not a strong opinion either way.
>>
>> On reflection, I think I'm actually fine with your original proposal
>> (separate tool - very generic management tool).  As a developer, this
>> tool would really come in handy - it allows me to manage newly
>> developed objects without the need to create a dedicated tool. Very
>> useful.
>
> That is indeed the rationale behind the tool. It always felt wrong to 
> me that you need to add explicit code just to recognise another class 
> of object in qpid-config. (I also dislike the fact that it defines its 
> own names for options).
>
>> I think my overall unease is with the rather large number of
>> configuration tools that we support. I'm really not crazy about how
>> we tend to create a new feature-specific configuration tool every
>> time we add a new feature to the broker.  I'd rather see a single
>> "top level" broker configuration command that supports all the
>> configuration aspects of the broker.  Openssl and NSS (certutil) take
>> this approach.   I think it would tend towards unifying the
>> configuration experience (e.g. naming of common options would be
>> consistent, need for familiarity with only one command, etc).
>>
>> I'm a bit biased. Guess I've found myself fixing the same defect
>> across multiple configuration tools a little too often (*cough*, SSL
>> configuration *cough*).  And I still keep having to remind myself
>> which option flag is used to specific a non-default broker address (?
>> is it "-a", or "-b"?).
>
> I sympathise entirely. For me its less the number of tools per se and 
> more that there is no clear, comprehensive, thought out strategy 
> around them.
>
> I don't want to make the situation worse. What I propose for 0.22 is 
> to add this new script into cpp/src/tests and install it in 
> libexec/qpid/tests along side other useful scripts and tools such as 
> qpid-send and qpid-cpp-benchmark. I'll also make it clear in the usage 
> text that the tool is experimental at this stage. That way its 
> available for those who want it, particularly those exploring 1.0 
> based networks, but its status is clear.
>
> Does that seem reasonable for now? We can then get some more time and 
> feedback on which to base more long term decisions.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


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

[Ken Giusti <kg...@redhat.com>]

----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: users@qpid.apache.org
> Sent: Thursday, March 21, 2013 11:47:38 AM
> Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
> 
> On 03/21/2013 01:19 PM, Ken Giusti wrote:
> > Hmmmm... seems like there's not a strong opinion either way.
> >
> > On reflection, I think I'm actually fine with your original
> > proposal
> > (separate tool - very generic management tool).  As a developer,
> > this
> > tool would really come in handy - it allows me to manage newly
> > developed objects without the need to create a dedicated tool.
> >  Very
> > useful.
> 
> That is indeed the rationale behind the tool. It always felt wrong to
> me
> that you need to add explicit code just to recognise another class of
> object in qpid-config. (I also dislike the fact that it defines its
> own
> names for options).
> 
> > I think my overall unease is with the rather large number of
> > configuration tools that we support. I'm really not crazy about how
> > we tend to create a new feature-specific configuration tool every
> > time we add a new feature to the broker.  I'd rather see a single
> > "top level" broker configuration command that supports all the
> > configuration aspects of the broker.  Openssl and NSS (certutil)
> > take
> > this approach.   I think it would tend towards unifying the
> > configuration experience (e.g. naming of common options would be
> > consistent, need for familiarity with only one command, etc).
> >
> > I'm a bit biased. Guess I've found myself fixing the same defect
> > across multiple configuration tools a little too often (*cough*,
> > SSL
> > configuration *cough*).  And I still keep having to remind myself
> > which option flag is used to specific a non-default broker address
> > (?
> > is it "-a", or "-b"?).
> 
> I sympathise entirely. For me its less the number of tools per se and
> more that there is no clear, comprehensive, thought out strategy
> around
> them.
> 
> I don't want to make the situation worse. What I propose for 0.22 is
> to
> add this new script into cpp/src/tests and install it in
> libexec/qpid/tests along side other useful scripts and tools such as
> qpid-send and qpid-cpp-benchmark. I'll also make it clear in the
> usage
> text that the tool is experimental at this stage. That way its
> available
> for those who want it, particularly those exploring 1.0 based
> networks,
> but its status is clear.
> 
> Does that seem reasonable for now? We can then get some more time and
> feedback on which to base more long term decisions.

+1


> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

-- 
-K

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

[Gordon Sim <gs...@redhat.com>]

On 03/21/2013 01:19 PM, Ken Giusti wrote:
> Hmmmm... seems like there's not a strong opinion either way.
>
> On reflection, I think I'm actually fine with your original proposal
> (separate tool - very generic management tool).  As a developer, this
> tool would really come in handy - it allows me to manage newly
> developed objects without the need to create a dedicated tool.  Very
> useful.

That is indeed the rationale behind the tool. It always felt wrong to me 
that you need to add explicit code just to recognise another class of 
object in qpid-config. (I also dislike the fact that it defines its own 
names for options).

> I think my overall unease is with the rather large number of
> configuration tools that we support. I'm really not crazy about how
> we tend to create a new feature-specific configuration tool every
> time we add a new feature to the broker.  I'd rather see a single
> "top level" broker configuration command that supports all the
> configuration aspects of the broker.  Openssl and NSS (certutil) take
> this approach.   I think it would tend towards unifying the
> configuration experience (e.g. naming of common options would be
> consistent, need for familiarity with only one command, etc).
>
> I'm a bit biased. Guess I've found myself fixing the same defect
> across multiple configuration tools a little too often (*cough*, SSL
> configuration *cough*).  And I still keep having to remind myself
> which option flag is used to specific a non-default broker address (?
> is it "-a", or "-b"?).

I sympathise entirely. For me its less the number of tools per se and 
more that there is no clear, comprehensive, thought out strategy around 
them.

I don't want to make the situation worse. What I propose for 0.22 is to 
add this new script into cpp/src/tests and install it in 
libexec/qpid/tests along side other useful scripts and tools such as 
qpid-send and qpid-cpp-benchmark. I'll also make it clear in the usage 
text that the tool is experimental at this stage. That way its available 
for those who want it, particularly those exploring 1.0 based networks, 
but its status is clear.

Does that seem reasonable for now? We can then get some more time and 
feedback on which to base more long term decisions.


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

[Fraser Adams <fr...@blueyonder.co.uk>]

On 21/03/13 13:19, Ken Giusti wrote:
>    I'd rather see a single "top level" broker configuration command that supports all the configuration aspects of the broker.  Openssl and NSS (certutil) take this approach.   I think it would tend towards unifying the configuration experience (e.g. naming of common options would be consistent, need for familiarity with only one command, etc).
>
Ooohhh now you're talking!! So I'll take it a stage further I'd like 
*very much* to see a unified approach that aligns configuration not just 
limited to "all the configuration aspects of the broker" but unified 
configuration and monitoring across the C++ and Java brokers (and 
beyond, wouldn't it be just grand to set a good precedent for unified 
AMQP management?).

I've made a bit of a start on this grand crazy vision, you might have 
seen my post at the weekend announcing a QmfManagementPlugin for the 
Java Broker. It might not be the "right" approach I'm taking, but hey 
I've got qpid-config and the QMF GUI both working with both brokers, 
which seems like a pretty decent start. The main limiting factor isn't 
so much "the control protocol" be it QMF/JMX/REST/whatever there remain 
some differences in the underlying management models which ought to be 
addressed - it's very frustrating when even for arguments with the same 
of very similar purposes the option name may be different between the 
brokers. Never mind just config aspects I'd quite like an AddressString 
that I had working on a client talking to the C++ broker to behave the 
same way when I talk to the Java broker.

I'm probably already sounding like a broken record on this topic, is it 
just me or do others share this crazy vision? If not is there a really 
compelling reason for the brokers behaving so differently?

Cheers,
Frase

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

[Ken Giusti <kg...@redhat.com>]

Hmmmm... seems like there's not a strong opinion either way.

On reflection, I think I'm actually fine with your original proposal (separate tool - very generic management tool).  As a developer, this tool would really come in handy - it allows me to manage newly developed objects without the need to create a dedicated tool.  Very useful.

I think my overall unease is with the rather large number of configuration tools that we support. I'm really not crazy about how we tend to create a new feature-specific configuration tool every time we add a new feature to the broker.  I'd rather see a single "top level" broker configuration command that supports all the configuration aspects of the broker.  Openssl and NSS (certutil) take this approach.   I think it would tend towards unifying the configuration experience (e.g. naming of common options would be consistent, need for familiarity with only one command, etc).

I'm a bit biased. Guess I've found myself fixing the same defect across multiple configuration tools a little too often (*cough*, SSL configuration *cough*).  And I still keep having to remind myself which option flag is used to specific a non-default broker address (? is it "-a", or "-b"?).

I'll stop grousing now... :)

----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: users@qpid.apache.org
> Sent: Tuesday, March 19, 2013 11:19:03 AM
> Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
> 
> On 03/19/2013 12:26 PM, Ken Giusti wrote:
> > While the attached script looks very useful, would you consider
> > adding those primitive commands to qpid-config instead?  Rather
> > than introduce a new tool, or adding new specialized domain/link
> > commands to qpid-config.
> >
> > I like those primitives - adding them to qpid-config would make
> > this de-facto qpid configuration command very flexible.  (And
> > would mean less work for the devs when new manageable type are
> > introduced).
> 
> I thought that might be confusing, i.e. having a tool that was a
> mixture
> of generic commands and more munged versions (add exchange v. create
> exchange).
> 
> However if this is in fact preferred, I'm happy to add it into
> qpid-config instead of adding a new tool. Any other
> views/preferences?
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

-- 
-K

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

[Gordon Sim <gs...@redhat.com>]

On 03/19/2013 12:26 PM, Ken Giusti wrote:
> While the attached script looks very useful, would you consider adding those primitive commands to qpid-config instead?  Rather than introduce a new tool, or adding new specialized domain/link commands to qpid-config.
>
> I like those primitives - adding them to qpid-config would make this de-facto qpid configuration command very flexible.  (And would mean less work for the devs when new manageable type are introduced).

I thought that might be confusing, i.e. having a tool that was a mixture 
of generic commands and more munged versions (add exchange v. create 
exchange).

However if this is in fact preferred, I'm happy to add it into 
qpid-config instead of adding a new tool. Any other views/preferences?


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

[Ken Giusti <kg...@redhat.com>]

----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: users@qpid.apache.org
> Sent: Monday, March 18, 2013 3:07:30 PM
> Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
> 
> On 03/14/2013 01:08 PM, Gordon Sim wrote:
> > As an additional but separate step I'd like to add some better
> > tooling
> > for this work. There are a couple of different options there. One
> > is to
> > extend the existing qpid-config tool to allow creation of domains
> > and
> > links to other 1.0 enabled entities. The other is to add a new tool
> > for
> > that purpose (this could be quite generic and thus usable for
> > creating,
> > deleting and listing objects of any type). I lean towards the

Hi Gordon,

While the attached script looks very useful, would you consider adding those primitive commands to qpid-config instead?  Rather than introduce a new tool, or adding new specialized domain/link commands to qpid-config.

I like those primitives - adding them to qpid-config would make this de-facto qpid configuration command very flexible.  (And would mean less work for the devs when new manageable type are introduced).

-K


> > second
> > option. If you have a view on that, let me know.
> 
> Attached is a script implementing the second option. Any comments,
> any
> objections to adding this, anyone prefer a different approach?
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

-- 
-K

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

[Gordon Sim <gs...@redhat.com>]

On 03/14/2013 01:08 PM, Gordon Sim wrote:
> As an additional but separate step I'd like to add some better tooling
> for this work. There are a couple of different options there. One is to
> extend the existing qpid-config tool to allow creation of domains and
> links to other 1.0 enabled entities. The other is to add a new tool for
> that purpose (this could be quite generic and thus usable for creating,
> deleting and listing objects of any type). I lean towards the second
> option. If you have a view on that, let me know.

Attached is a script implementing the second option. Any comments, any 
objections to adding this, anyone prefer a different approach?

Re: [c++]: Progressing AMQP 1.0 support for 0.22 release

[Gordon Sim <gs...@redhat.com>]

On 02/15/2013 06:22 PM, Gordon Sim wrote:
> 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.

This is now ready to commit (I have added some automated tests and fixed 
a few issues that came up). Though the alpha period is now over, I don't 
see these changes as problematic for the beta. They only affect the 1.0 
implementation and are optional enhancements to that. The details of the 
change have been available for review and comment for some time. So, 
unless anyone objects I'll be committing the update shortly.

As an additional but separate step I'd like to add some better tooling 
for this work. There are a couple of different options there. One is to 
extend the existing qpid-config tool to allow creation of domains and 
links to other 1.0 enabled entities. The other is to add a new tool for 
that purpose (this could be quite generic and thus usable for creating, 
deleting and listing objects of any type). I lean towards the second 
option. If you have a view on that, let me know.



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

[Gordon Sim <gs...@redhat.com>]

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.


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

[Gordon Sim <gs...@redhat.com>]

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!

Re: [c++]: Progressing AMQP 1.0 support for 0.22 release

[Gordon Sim <gs...@redhat.com>]

On 02/04/2013 04:59 PM, Steve Huston wrote:
> Ok, good. I was concerned because I've heard of a major possible AMQP using community who elected not to use AMQP because of the lack of broker federation standardization. I would like this point squashed.

Yes, I have also heard that being raised.  As I say, there is nothing to 
stop a broker establishing links (for message flow in either direction) 
to a process that is in fact another broker implementation.

Whether a give broker supports this and the mechanism by which you 
trigger it will vary from one implementation to another. However the 
actual establishment of the link and the transfer of messages over it is 
standard AMQP that should be supported by any broker (since it is 
indistinguishable from what a sending or receiving client would be doing).

Out of curiosity, what did they use instead? I don't think there is 
anything that standardises more of the problem than AMQP does.

> 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).

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

[Carl Trieloff <cc...@redhat.com>]

On 02/04/2013 11:59 AM, Steve Huston wrote:
> Ok, good. I was concerned because I've heard of a major possible AMQP using community who elected not to use AMQP because of the lack of broker federation standardization.

I find that amusing, someone would rather select something entirely
proprietary? Sounds to me like they where just looking for an excuse to
do something else.

Carl.

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

[Steve Huston <sh...@riverace.com>]

Ok, good. I was concerned because I've heard of a major possible AMQP using community who elected not to use AMQP because of the lack of broker federation standardization. I would like this point squashed. 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?

-Steve

> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: Monday, February 04, 2013 11:57 AM
> To: users@qpid.apache.org
> Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
> 
> On 02/04/2013 04:14 PM, Steve Huston wrote:
> > Hi Gordon,
> >
> >> I hope to make some further progress with AMQP 1.0 support for the
> >> next release. Some of the gaps remaining are:
> >>
> >> * inter-broker links
> >>
> >> This allows qpidd to be hooked into wider 1.0 based networks which
> >> expands the options for building or evolving systems.
> >
> > Does this require any work/contribution from the AMQP TC?
> 
> Another good question!
> 
> In establishing a link to another broker, qpidd is not doing anything that other
> client libraries must be able to do. From the perspective of that other broker
> qpidd can be treated as just another producer or consumer.
> 
> However there are aspects that will certainly benefit from more activity in
> the standards group. The handling of reply-to in networks of different broker
> implementations is a good example.
> 
> So while I think this work can (and should) get started now, I think it will also
> ultimately need to be updated to take account of further detail on the syntax
> and semantics of an 'address-string', any standardisation efforts around
> management (mechanism and schema) etc.
> 
> --Gordon.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional
> commands, e-mail: users-help@qpid.apache.org


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

[Gordon Sim <gs...@redhat.com>]

On 02/04/2013 04:14 PM, Steve Huston wrote:
> Hi Gordon,
>
>> I hope to make some further progress with AMQP 1.0 support for the next
>> release. Some of the gaps remaining are:
>>
>> * inter-broker links
>>
>> This allows qpidd to be hooked into wider 1.0 based networks which expands
>> the options for building or evolving systems.
>
> Does this require any work/contribution from the AMQP TC?

Another good question!

In establishing a link to another broker, qpidd is not doing anything 
that other client libraries must be able to do. From the perspective of 
that other broker qpidd can be treated as just another producer or consumer.

However there are aspects that will certainly benefit from more activity 
in the standards group. The handling of reply-to in networks of 
different broker implementations is a good example.

So while I think this work can (and should) get started now, I think it 
will also ultimately need to be updated to take account of further 
detail on the syntax and semantics of an 'address-string', any 
standardisation efforts around management (mechanism and schema) etc.

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

[Steve Huston <sh...@riverace.com>]

Hi Gordon,

> I hope to make some further progress with AMQP 1.0 support for the next
> release. Some of the gaps remaining are:
> 
> * inter-broker links
> 
> This allows qpidd to be hooked into wider 1.0 based networks which expands
> the options for building or evolving systems.

Does this require any work/contribution from the AMQP TC?

-Steve



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org