Closed
Conversation
Motivation: When Netty components are initialized, Netty attempts to determine if it has access to unsafe. If Netty is not able to access unsafe (because of security permissions, or because the JVM was started with an explicit flag to tell Netty to not look for unsafe), Netty logs an info-level message that looks like a warning: Your platform does not provide complete low-level API for accessing direct buffers reliably. Unless explicitly requested, heap buffer will always be preferred to avoid potential system unstability. This log message can appear in applications that depend on Netty for networking, and this log message can be scary to end-users of such platforms. This log message should not be emitted if the application was started with an explicit flag telling Netty to not look for unsafe. Modifications: This commit refactors the unsafe detection logic to expose whether or not the JVM was started with a flag telling Netty to not look for unsafe. With this exposed information, the log message on unsafe being unavailable can be modified to not be emitted when Netty is explicitly told to not look for unsafe. Result: No log message is produced when unsafe is unavailable because Netty was told to not look for it.
Member
|
lgtm |
Member
|
Cherry-picked into 4.1 (0b086a9) and 4.0 (d0bef36) @jasontedor thanks |
Contributor
Author
|
Thanks @normanmaurer. |
This was referenced May 3, 2017
seut
added a commit
to seut/netty
that referenced
this pull request
Jul 9, 2018
Motivation: Users should not see a scary log message when Netty is initialized if Netty configuration explicitly disables unsafe. The log message that produces this warning was previously guarded but by recent refactoring a bug was introduced inside the guard helper method. Modifications: This commit brings back the guard against the scary log message if unsafe is explicitly disabled. Result: No log message is produced when unsafe is unavailable because Netty was told to not look for it. Relates netty#5624, netty#6696
normanmaurer
pushed a commit
that referenced
this pull request
Jul 9, 2018
Motivation: Users should not see a scary log message when Netty is initialized if Netty configuration explicitly disables unsafe. The log message that produces this warning was previously guarded but by recent refactoring a bug was introduced inside the guard helper method. Modifications: This commit brings back the guard against the scary log message if unsafe is explicitly disabled. Result: No log message is produced when unsafe is unavailable because Netty was told to not look for it. Relates #5624, #6696
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Motivation:
When Netty components are initialized, Netty attempts to determine if it
has access to unsafe. If Netty is not able to access unsafe (because of
security permissions, or because the JVM was started with an explicit
flag to tell Netty to not look for unsafe), Netty logs an info-level
message that looks like a warning:
Your platform does not provide complete low-level API for accessing
direct buffers reliably. Unless explicitly requested, heap buffer will
always be preferred to avoid potential system unstability.
This log message can appear in applications that depend on Netty for
networking, and this log message can be scary to end-users of such
platforms. This log message should not be emitted if the application was
started with an explicit flag telling Netty to not look for unsafe.
Modifications:
This commit refactors the unsafe detection logic to expose whether or
not the JVM was started with a flag telling Netty to not look for
unsafe. With this exposed information, the log message on unsafe being
unavailable can be modified to not be emitted when Netty is explicitly
told to not look for unsafe.
Result:
No log message is produced when unsafe is unavailable because Netty was
told to not look for it.