On 3/12/24 16:25, Ciaran wrote:
On Tue, Mar 12, 2024 at 7:13 PM Timothy Bish <tabish...@gmail.com> wrote:
On 3/12/24 04:08, Ciaran wrote:
On Mon, Mar 11, 2024 at 9:33 PM Timothy Bish <tabish...@gmail.com>
wrote:
The client re-connection logic treats a SASL authentication error as a
terminal state and will not continue reconnect attempts if it receives a
SASL outcome that indicates anything other than a temporary failure
state so it should be stopping the reconnect if it was actually failing
to authenticate. This is true on the first attempt as well as on
subsequent attempts to other hosts if you add more than one and it has
failed to reach any of the preceding hosts while attempt to recover the
connection.
From the error logs attached it doesn't appear as though SASL
authentication is your issue though, at least in so much as it isn't
logging anything indicating SASL authentication as the error. Instead
the connection appears to be failing because the remote has sent a
response to the Receiver attach that does not include the initial
delivery count value as required by the specification.
You can capture more information about the AMQP frames being sent and
received by enabling frame tracing, see the docs for how to do that.
https://github.com/apache/qpid-protonj2/blob/main/protonj2-client-docs/Configuration.md#logging
Thanks for getting back to me so quickly Tim, please find below the
frames
for a successful
connection and an unsuccessful connection. My test has actually been to
specify an invalid user if
that's relevant.
I can see in both cases that the SASL challenge completes successfully,
which I appreciate is
strange, but I would imagine Azure Service Bus is a common enough broker
target for the library?
So looking at the frame trace it is clear the connection is being
established as the SASL outcome is returned as 'OK' and then a normal
Open exchange occurs so from the client point of view a connection was
successfully made so any initial reconnect attempts option won't apply
here as the connection "succeeded". For the connection to fail with bad
credentials the SASL outcome would need to indicate a failure.
The connection breaks at the point the attach response arrives and is
lacking the mandatory initial-delivery-count field as per the AMQP 1.0
specification.
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-attach
It could be that the user you logged in as does not have read permission
and the server is trying to tell the client that the link will be closed
with an error condition in the Detach indicating that as the returned
response does not carry a source or target value (both are null) whereas
the sent Attach has an appropriate source and target value. If that is
what it is doing it gets it wrong as it omits the
'initial-delivery-count' which is required for an Attach with the Role
of Sender (as per referenced spec above) regardless of the outcome of
the attach.
Sorry, I think perhaps I've not explained myself well here, the user is
correctly configured on Azure Service Bus.
However, the fail case is where I provide an *invalid* (non-existant) user
or an *invalid* password.
I can see that the SaSL challenges succeeds, and agree from a client
perspective that this success is
problematic when the credentials provided are invalid! I guess I'm flagging
that my configuration is not
exotic, and Azure Service Bus is a fairly popular AMQP broker.
As I pointed out the remote is telling the client that the connection
succeeded so from the client point of view there just isn't anything
that it can do here to know that your user doesn't exist. I'd say you
need to take this up with MS as there just isn't anything that can be
done here.
If this is the desired behaviour of the client library when interacting
with Azure, I'll stick with my work around, which is to create a
connection & receiver with no reconnect semantics configured, check that
connection succeeds, close it and then
re-open with a retryable connection.
P.S. Spotted a minor issue in the ReconnectOptions.java file and have
submitted a pull request over on Github,
confused the hell out of me for a while!
- Cj.
--
Tim Bish
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
