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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
