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