8000 spanner-jdbc: Don't call getExitingExecutorService in StatementExecutor by nevinheintze · Pull Request #6170 · googleapis/google-cloud-java · GitHub
[go: up one dir, main page]

Skip to content

Conversation

@nevinheintze
Copy link
@nevinheintze nevinheintze commented Aug 27, 2019

Remove call to getExitingExecutorService when we create a new
ThreadPoolExecutor in spanner-jdbc's StatementExecutor.

Calling getExitingExecutorService converts the ThreadPoolExecutor into an
ExecutorService that exits when the application is complete i.e. we keep
around the ThreadPoolExecutor and won't GC it. Given that we allocate a new
ThreadPoolExecutors for every StatementExecutor, this is effectively a
memory leak since the ThreadPoolExecutors is kept around after
StatementExecutor is GC'd and the ThreadPoolExecutor has been shutdown. It
can lead to substantial memory usage if an app uses many
StatementExecutors.

ThreadPoolExecutor to be GC'd when StatementExecutor is finished
(getExitingExecutorService will keep it around until application
exits).

Keeping all ThreadPoolExecutors around is effectively a memory leak,
and can lead to substantial memory increase if an app uses many
StatementExecutors.
@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Aug 27, 2019
@nevinheintze nevinheintze requested a review from olavloite August 27, 2019 05:19
@nevinheintze nevinheintze changed the title Don't call getExitingExecutorService in StatementExecutor spanner-jdbc: Don't call getExitingExecutorService in StatementExecutor Aug 27, 2019
@olavloite olavloite added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Aug 27, 2019
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Aug 27, 2019
@olavloite
Copy link

Good spot. The method was called to ensure that the executor would use a daemon ThreadFactory, but that is not necessary as it is already passed a ThreadFactory that produces daemon threads. But the MoreExecutors.getExitingExecutorService would also add a shutdown hook which kept the executor in memory.

@olavloite
Copy link

The failed build on Windows Java 8 is unrelated to this PR, and is fixed by #6174.

Copy link
@olavloite olavloite left a comment

Choose a reason for hiding this comment

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

LGTM. The original reason for calling getExitingExecutorService was to ensure it used daemon threads. That is not needed as it is handed a ThreadFactory that already does that.

@olavloite olavloite requested a review from kolea2 August 27, 2019 12:31
@olavloite
Copy link

@kolea2 Could you have a quick look as well?

Copy link
Contributor
@kolea2 kolea2 left a comment

Choose a reason for hiding this comment

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

LGTM, thank you!

@kolea2 kolea2 merged commit cdf3c37 into googleapis:master Aug 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes This human has signed the Contributor License Agreement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

0