This repository was archived by the owner on Jan 24, 2024. It is now read-only.
Fix thread safety issue for MessageFetchContext #1049
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BewareMyPower
added
release/2.10.0
release/2.8.2.x
release/2.9.1
type/bug
type/enhancement
Demogorgon314
approved these changes
Feb 3, 2022
BewareMyPower
added a commit
that referenced
this pull request
Feb 3, 2022
### Motivation There is a thread safety issue for `MessageFetchContext`. The instance of that this class could be accessed by different threads. For example, I added some logs to each method and saw the following output: | Thread name | Method name | | ------------------------------------------- | ----------------------- | | pulsar-io-18-12 | `MessageFetchContext` | | pulsar-io-18-12 | `handleFetch` | | pulsar-io-18-12 | `handlePartitionData` | | pulsar-io-18-12 | `checkOffsetOutOfRange` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `readEntries` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `handleEntries` | | metadata-store-19-1 | `tryComplete` | | metadata-store-19-1 | `complete` | | metadata-store-19-1 | `recycle` | Though all fields are never modified before `recycle()` is called, the visibility of these fields cannot be guaranteed without `volatile`. ### Modifications - Add `volatile` keyword to fields of `MessageFetchContext` except the atomic variables and thread safe containers. - For atomic variables and thread safe containers, make them `final` and initialize them in the constructor. In `recycle()` method, instead of resetting them with `null` values, just reset them to the default state. This PR can also improve the performance. Because even if `MessageFetchContext` is managed by the Netty object pool, each time it's allocated from `MessageFetchContext#get`, the atomic variables and thread safe containers are still allocated from heap memory.
BewareMyPower
added a commit
that referenced
this pull request
Feb 3, 2022
### Motivation There is a thread safety issue for `MessageFetchContext`. The instance of that this class could be accessed by different threads. For example, I added some logs to each method and saw the following output: | Thread name | Method name | | ------------------------------------------- | ----------------------- | | pulsar-io-18-12 | `MessageFetchContext` | | pulsar-io-18-12 | `handleFetch` | | pulsar-io-18-12 | `handlePartitionData` | | pulsar-io-18-12 | `checkOffsetOutOfRange` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `readEntries` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `handleEntries` | | metadata-store-19-1 | `tryComplete` | | metadata-store-19-1 | `complete` | | metadata-store-19-1 | `recycle` | Though all fields are never modified before `recycle()` is called, the visibility of these fields cannot be guaranteed without `volatile`. ### Modifications - Add `volatile` keyword to fields of `MessageFetchContext` except the atomic variables and thread safe containers. - For atomic variables and thread safe containers, make them `final` and initialize them in the constructor. In `recycle()` method, instead of resetting them with `null` values, just reset them to the default state. This PR can also improve the performance. Because even if `MessageFetchContext` is managed by the Netty object pool, each time it's allocated from `MessageFetchContext#get`, the atomic variables and thread safe containers are still allocated from heap memory. (cherry picked from commit 0f1f826)
BewareMyPower
added a commit
that referenced
this pull request
Feb 3, 2022
### Motivation There is a thread safety issue for `MessageFetchContext`. The instance of that this class could be accessed by different threads. For example, I added some logs to each method and saw the following output: | Thread name | Method name | | ------------------------------------------- | ----------------------- | | pulsar-io-18-12 | `MessageFetchContext` | | pulsar-io-18-12 | `handleFetch` | | pulsar-io-18-12 | `handlePartitionData` | | pulsar-io-18-12 | `checkOffsetOutOfRange` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `readEntries` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `handleEntries` | | metadata-store-19-1 | `tryComplete` | | metadata-store-19-1 | `complete` | | metadata-store-19-1 | `recycle` | Though all fields are never modified before `recycle()` is called, the visibility of these fields cannot be guaranteed without `volatile`. ### Modifications - Add `volatile` keyword to fields of `MessageFetchContext` except the atomic variables and thread safe containers. - For atomic variables and thread safe containers, make them `final` and initialize them in the constructor. In `recycle()` method, instead of resetting them with `null` values, just reset them to the default state. This PR can also improve the performance. Because even if `MessageFetchContext` is managed by the Netty object pool, each time it's allocated from `MessageFetchContext#get`, the atomic variables and thread safe containers are still allocated from heap memory. (cherry picked from commit 0f1f826)
BewareMyPower
added a commit
that referenced
this pull request
Feb 9, 2022
### Motivation There is a thread safety issue for `MessageFetchContext`. The instance of that this class could be accessed by different threads. For example, I added some logs to each method and saw the following output: | Thread name | Method name | | ------------------------------------------- | ----------------------- | | pulsar-io-18-12 | `MessageFetchContext` | | pulsar-io-18-12 | `handleFetch` | | pulsar-io-18-12 | `handlePartitionData` | | pulsar-io-18-12 | `checkOffsetOutOfRange` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `readEntries` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `handleEntries` | | metadata-store-19-1 | `tryComplete` | | metadata-store-19-1 | `complete` | | metadata-store-19-1 | `recycle` | Though all fields are never modified before `recycle()` is called, the visibility of these fields cannot be guaranteed without `volatile`. ### Modifications - Add `volatile` keyword to fields of `MessageFetchContext` except the atomic variables and thread safe containers. - For atomic variables and thread safe containers, make them `final` and initialize them in the constructor. In `recycle()` method, instead of resetting them with `null` values, just reset them to the default state. This PR can also improve the performance. Because even if `MessageFetchContext` is managed by the Netty object pool, each time it's allocated from `MessageFetchContext#get`, the atomic variables and thread safe containers are still allocated from heap memory. (cherry picked from commit 0f1f826)
lhotari
added a commit
to lhotari/kop
that referenced
this pull request
Feb 11, 2022
- streamnative#1049 changed behavior, therefore this change is needed
BewareMyPower
pushed a commit
that referenced
this pull request
Feb 11, 2022
- #1049 changed behavior, therefore this change is needed
BewareMyPower
pushed a commit
that referenced
this pull request
Feb 11, 2022
BewareMyPower
pushed a commit
that referenced
this pull request
Feb 11, 2022
BewareMyPower
pushed a commit
that referenced
this pull request
Feb 11, 2022
eolivelli
pushed a commit
to eolivelli/kop
that referenced
this pull request
Feb 24, 2022
### Motivation There is a thread safety issue for `MessageFetchContext`. The instance of that this class could be accessed by different threads. For example, I added some logs to each method and saw the following output: | Thread name | Method name | | ------------------------------------------- | ----------------------- | | pulsar-io-18-12 | `MessageFetchContext` | | pulsar-io-18-12 | `handleFetch` | | pulsar-io-18-12 | `handlePartitionData` | | pulsar-io-18-12 | `checkOffsetOutOfRange` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `readEntries` | | BookKeeperClientWorker-OrderedExecutor-10-0 | `handleEntries` | | metadata-store-19-1 | `tryComplete` | | metadata-store-19-1 | `complete` | | metadata-store-19-1 | `recycle` | Though all fields are never modified before `recycle()` is called, the visibility of these fields cannot be guaranteed without `volatile`. ### Modifications - Add `volatile` keyword to fields of `MessageFetchContext` except the atomic variables and thread safe containers. - For atomic variables and thread safe containers, make them `final` and initialize them in the constructor. In `recycle()` method, instead of resetting them with `null` values, just reset them to the default state. This PR can also improve the performance. Because even if `MessageFetchContext` is managed by the Netty object pool, each time it's allocated from `MessageFetchContext#get`, the atomic variables and thread safe containers are still allocated from heap memory. (cherry picked from commit 0f1f826)
eolivelli
pushed a commit
to eolivelli/kop
that referenced
this pull request
Feb 24, 2022
- streamnative#1049 changed behavior, therefore this change is needed
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NOTE: This PR introduced a memory leak that was first introduced in release 2.8.2.6, 2.9.2.2. And will be fixed by #1069.
Motivation
There is a thread safety issue for
MessageFetchContext. The instance of that this class could be accessed by different threads. For example, I added some logs to each method and saw the following output:MessageFetchContexthandleFetchhandlePartitionDatacheckOffsetOutOfRangereadEntrieshandleEntriestryCompletecompleterecycleThough all fields are never modified before
recycle()is called, the visibility of these fields cannot be guaranteed withoutvolatile.Modifications
volatilekeyword to fields ofMessageFetchContextexcept the atomic variables and thread safe containers.finaland initialize them in the constructor. Inrecycle()method, instead of resetting them withnullvalues, just reset them to the default state.This PR can also improve the performance. Because even if
MessageFetchContextis managed by the Netty object pool, each time it's allocated fromMessageFetchContext#get, the atomic variables and thread safe containers are still allocated from heap memory.