On Tue, Mar 12, 2024 at 8:42 PM Timothy Bish <tabish...@gmail.com> wrote:
> 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 Indeed, not a problem, I've a work-around in place! Thank you.
