mssql-jdbc: SQLServerConnection hangs after logging the following statement: "Sending federated authentication token."

Driver version

11.2.1.jre17

SQL Server version

Microsoft SQL Azure (RTM) - 12.0.2000.8 Jan 12 2023 05:25:39 Copyright © 2022 Microsoft Corporation

Client Operating System

Ubuntu 20.04.5 LTS

JAVA/JVM version

openjdk version “17.0.5” 2022-10-18 OpenJDK Runtime Environment Temurin-17.0.5+8 (build 17.0.5+8) OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (build 17.0.5+8, mixed mode, sharing)

Problem description

At some point of time any individual SQLServerConnection may hang after logging the following statement: ConnectionID:{traceID} ClientConnectionId: {clientConnectionId} Sending federated authentication token. The connections don’t fail with any errors and don’t recover. Only application restart helps to resolve the issue.

Expected behavior

SQLServerConnection should successfully log the following statements and execute a corresponding SQL query.

ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb Sending federated authentication token.
ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb Received feature extension acknowledgement for Data Classification.
ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb Received feature extension acknowledgement for UTF8 support.
ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb Network packet size is 8000 bytes
ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb Received feature extension acknowledgement for AE.
ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb Received feature extension acknowledgement for Azure SQL DNS Caching.
ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb Received feature extension acknowledgement for Idle Connection Resiliency.
ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb Received feature extension acknowledgement for federated authentication.
ConnectionID:12180 ClientConnectionId: 9e5151cc-d906-4533-8cca-9ad30cf46deb End of connect

Actual behavior

SQLServerConnection hangs without any further notice after the following log statement:

ConnectionID:12217 ClientConnectionId: fb3d38e1-d673-4c95-a552-5be541556a3f Sending federated authentication token.

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 36 (19 by maintainers)

Most upvoted comments

I was talking to the team and we revisited our timeout logic. Right now, how the driver does timeouts doesn’t look right to us. It isn’t right that our current socketTimeout logic is affecting both your queries and login. I’m marking this issue as an enhancement to fix this. The general idea for the fix is to have the timeouts during login (where your hang occurs) be respected separately from the timeout that occurs when you run your long queries (so that you won’t have to have 3min affecting both login and queries).

For now as a workaround, can you open connections with socketTImeout=3min for your longer running queries? And, for all other cases have it remain as 30s? Just so you can somewhat efficiently identify hang.

@tkyc Thank you for the answers! I think we may close the issue as resolved. In case of any further issues or concerns I will re-open it.

@alromos

  1. That’s right, Managed Identity in 12.x.x versions of the driver rely on azure-identity now to get the access token for authenticating. So, from 12.x.x onwards you’ll need to explicitly include azure-identity as a dependency.

  2. That should happen after our next preview. Our next preview is on June 7th, but for our next stable release I’ll need to double check confirm. I’ll let you know when I get the exact date.

EDIT: Stable release will be on end of July

Interesting… right after that Reading response... log message there’s this block of code:

            if (isAdaptive) {
                tdsReader.readPacket();
            } else {
                while (tdsReader.readPacket());
            }

isAdaptive should be false, which means it hits that while loop. I’m starting to think that it might not be breaking out of that while loop. I’ll need to investigate some more, if that’s the case.

@Jeffery-Wasty @tkyc JFYI I’ve enabled the additional logging you requested and now am waiting for the issue to be reproduced. Will keep you posted.