Databricks driver frequent timeout

[hussef01]

Hi @anthonysena,

We upgraded our WebAPI to v2.15.0 and switched to DatabricksJDBC42.jar v2.7.3 for connecting to our OMOP CDM. Since then, cohort generation calls immediately time out—despite a very large socketTimeout setting. Occasionally, if we rerun the generation a few times it succeeds, but it almost always fails on the first attempt.

We didn’t see this issue with SparkJDBC42.jar (v2.6.22 and earlier). Have you encountered this behavior, and do you have any suggestions for resolving it?

[konstjar]

There is special profile for DatabricksJDBC42.jar
https://github.com/OHDSI/WebAPI/blob/master/pom.xml#L1525

Can you confirm you have the issue with that one?

[hussef01]

@konstjar Are you suggesting to downgrade the driver to 2.6.34? What would I have to change in the configuration? We are using the Broadsea installation.

[konstjar]

My point is that there are 2 different configuration profiles in WebAPI: one for Spark driver and different one for Databricks. And it looks like from your message that you are trying to replace SparkJDBC42.jar driver with DatabricksJDBC42.jar by using Spark profile. It will not work correctly.

[hussef01]

Thank you, @konstjar. I'm already using the Databricks profile. Atlas is recognizing the driver correctly, but the functionality within Atlas is failing and/or times out. I can connect successfully using both drivers; however, SparkJDBC42 works flawlessly, while DatabricksJDBC42 is having issues in Atlas.

For reference, here are the two connection formats I'm working with:
SparkJDBC42 connects and all functions work
jdbc:spark://:443/default;transportMode=http;ssl=1;httpPath=;AuthMech=3;UID=token;PWD=

DatabricksJDBC42 connects but functions do NOT always work:
jdbc:databricks://:443;httpPath=;AuthMech=3;UID=token;PWD=

[konstjar]

I see, thank you for clarification.

I can suggest 2 options:

1. Double check Databricks JDBC driver documentation for your version about Timeout/socketTimeout options and parameters. Most likely there are some parameters that you can pass in connection string. Also, you can enable verbose logging on JDBC side to see the root cause.
2. In worst case scenario, rolling back to v2.6.34 is an alternative.

[anthonysena]

@hussef01 I can confirm that we are using the DataBricks JDBC driver v2.6.34 with v2.15 of Atlas without the timeout issue. That said, we are not using Broadsea for the deployment so I think the suggestions offered by @konstjar are good next steps to try.