Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dialogue attempts not to retain context classloaders #1912

Draft
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

carterkozak
Copy link
Contributor

Dialogue didn't behave well in systems using classloaders which must be unloaded later.

After this PR

==COMMIT_MSG==
Dialogue attempts not to retain context classloaders
==COMMIT_MSG==

Possible downsides?

The cleaner thread is no longer named something that points to dialogue. We could use the same ThreadFactory utility that I adopted elsewhere, however the cleaner is the most important thread to clean up (the others will expire) and the default constructor uses an internal InnocuousThread implementation which does an even better job of avoiding holding external references.

@changelog-app
Copy link

changelog-app bot commented Apr 18, 2023

Generate changelog in changelog/@unreleased

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

Dialogue attempts not to retain context classloaders

Check the box to generate changelog(s)

  • Generate changelog entry

.build());
// Ideally we would use a name pattern like 'dialogue-cleaner-%d', however it's more important
// that this cleaner does not retain context classloader references.
private static final Cleaner cleaner = Cleaner.create();
Copy link
Contributor

Choose a reason for hiding this comment

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

Could not use ThreadFactoryBuilder and impl from scratch?

Copy link
Contributor Author

@carterkozak carterkozak Apr 19, 2023

Choose a reason for hiding this comment

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

Not quite, cleaner has some special case logic to clear threadlocal data after cleaning objects when the thread implementation is the internal default (InnocuousThread) here. Unfortunately it becomes complex to duplicate that logic (requires Unsafe apis)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants