Skip to content

fix(bigquery-jdbc): stop producer and release resources on ResultSet.close - #14712

Merged
logachev merged 6 commits into
mainfrom
kirl/htapi_cleanup_on_close
Oct 21, 2026
Merged

logachev merged 6 commits into
mainfrom
kirl/htapi_cleanup_on_close

Conversation

@logachev

Copy link
Copy Markdown
Contributor

Ensure when ResultSet is closed, we stop reading arrow stream as well

@logachev
logachev requested review from a team as code owners October 21, 2026 04:04

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request improves resource cleanup, concurrency handling, and exception safety across BigQueryArrowResultSet, BigQueryJsonResultSet, and BigQueryStatement. Key changes include adding idempotency checks and resource cleanup in result set close() methods, replacing uninterruptible queue operations with standard interruptible operations, and introducing a helper method isWorkerShuttingDown() to check thread and executor states. Feedback suggests wrapping the custom resource cleanup in BigQueryArrowResultSet.close() in a try-finally block to guarantee super.close() is always executed, and leveraging the new isWorkerShuttingDown() helper in BigQueryStatement to simplify checks and avoid potential NullPointerExceptions.


private final BigQueryJdbcCustomLogger LOG = new BigQueryJdbcCustomLogger(this.toString());
public static final int DEFAULT_BUFFER_SIZE = BigQuerySettings.DEFAULT_NUM_BUFFERED_ROWS * 2;
static final int DEFAULT_ARROW_BUFFER_SIZE = 32;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess making default 32 makes sense but I wonder if this info should be added/explained somewhere or also if this should be a configurable conn prop?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the rationale behind 32 as the hardcoded number?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an arbitrary constant. If consumer apps is reading data faster than we're fetching, buffer will be ~empty most of the time, if it is slower, we need some limit (similar to how we store 2 pages of results for Json).

We can make it configurable, but I'm not sure there is a lot of value in tweaking it.. Buffer is likely to be either empty or full in either case.

@logachev
logachev merged commit 6b99452 into main Oct 21, 2026
199 checks passed
@logachev
logachev deleted the kirl/htapi_cleanup_on_close branch October 21, 2026 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants