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

Refactor IO thread pool usage #3007

Merged
merged 5 commits into from
Jul 8, 2019

Conversation

pomadchin
Copy link
Member

@pomadchin pomadchin commented Jun 25, 2019

Overview

This PR refactors GeoTrellis blocking thread pool usages. Instead of having multiple thread pools for each particular backend / reader / writer there would be a single and configurable thread pool. By default it is a FixedThreadPool with a geotrellis-default-io-%d name. In addition to that, it was decided to make it configurable by user. This PR allows users to use their own thread pools for all kind of readers / writers.

In this PR we also introduced a new way to pass objects that should not be serialized (ExecutionContext and S3Client) into objects constructors. Instead of passing a function to create an instance of a thing, it was decided to pass these objects as by-name parameters. Such approach allows to simplify the API and makes the API more transparent.

This PR touches all the project configuration files, and with this PR we introduce hyphen-separated case usage by default instead of a camel-case.

  • docs/CHANGELOG.rst updated, if necessary
  • Test on EMR configurable common fixed thread pool
  • Test on EMR execution context passed instead of a threads number

Closes #2945

@pomadchin pomadchin force-pushed the feature/thread-pool branch 2 times, most recently from 115e010 to 109a225 Compare June 25, 2019 23:48
@pomadchin pomadchin self-assigned this Jun 26, 2019
@pomadchin pomadchin force-pushed the feature/thread-pool branch 3 times, most recently from 0914285 to d81ecd0 Compare June 27, 2019 13:04
abstract class COGCollectionLayerReader[ID] { self =>
implicit val ec: ExecutionContext
Copy link
Contributor

Choose a reason for hiding this comment

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

This is weird for two reasons.

  1. COGCollectionLayerReader is already abstract class, why not just make it a constructor parameter, that is way more explicit
  2. Is it very painful to have this be non implicit? Its a little difficult to see where it is used .

Copy link
Member Author

Choose a reason for hiding this comment

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

For the COGCollectionLayerReader.read I think it makes not a lot of sense to pass execution context explicitly in the code that can work only 'locally' and is internal API in fact.

Copy link
Member Author

Choose a reason for hiding this comment

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

Also do I understand correct that your 1. comment can be applied to all our abstract classes? (CollectionLayerReader for instance)

@pomadchin pomadchin force-pushed the feature/thread-pool branch 2 times, most recently from 430c683 to f4e9b05 Compare July 1, 2019 23:13
@echeipesh echeipesh merged commit f1758b2 into locationtech:master Jul 8, 2019
@pomadchin pomadchin deleted the feature/thread-pool branch July 12, 2019 02:21
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.

Refactor IO thread pool usage
2 participants