-
Notifications
You must be signed in to change notification settings - Fork 834
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
Allow SDK to run in environments prohibiting use of sun.misc.Unsafe #4902
Conversation
|
The Individual CLA option is not enabled for this project. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx @rrva! do you have any ideas on how to run some(?) tests under the security manager?
hi @rrva, it should be, can you attach a screenshot of what you see? |
Signed. Yesterday I got an error saying the individual option was not enabled and I should contact the project admin. |
I have added a test and squashed all commits |
Codecov ReportBase: 90.93% // Head: 90.96% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #4902 +/- ##
============================================
+ Coverage 90.93% 90.96% +0.03%
- Complexity 4817 4820 +3
============================================
Files 545 545
Lines 14383 14388 +5
Branches 1383 1384 +1
============================================
+ Hits 13079 13088 +9
+ Misses 901 897 -4
Partials 403 403
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
da4d961
to
919d292
Compare
I get higher code coverage of JcTools.java than codecov when checking with "Run with coverage" in IntelliJ. What could be wrong? |
@trask Please have a look at what I could do to the coverage issue of JcTools.java, it's a bit tricky. I think what is happening is that MpscArrayQueueProducerIndexField.P_INDEX_OFFSET is sometimes sucessfully initialized before the SunMiscProhibitedSecurityManager is installed. Since it is a static field it is only initialized once per JVM invocation, it stays that way. This initialization is needed to fail if JcToolsSecurityManagerTest is to be allowed to cover the code paths I have changed. I'm a bit unsure if this theory holds but thats what I think is happening when running jacoco. I think we either need to find a way that jacoco runs JcToolsSecurityManagerTest in an isolated jvm or excluding the changed code from coverage checks. When I run JcToolsSecurityManagerTest and JcToolsTest test separately in IntelliJ I do get coverage on all paths. When I run JcToolsSecurityManagerTest without the changes in this PR it fails as expected. |
...haded-deps/src/test/java/io/opentelemetry/sdk/trace/internal/JcToolsSecurityManagerTest.java
Outdated
Show resolved
Hide resolved
codecov is claiming quite a bit of uncovered new code in this PR. Can you add more test cases to cover what it says isn't covered? |
I simplified the actual change to the code down to a single line, the rest is test code (which jacoco has trouble recognizing coverage of when running the entire projects' tests). It also needs this ugly thing (only in the build.gradle.kts of the sdk/trace-shaded-deps module which today only contains a single other test)
If you're fine with that, thats OK by me. OR, I drop the entire test since:
|
sorry the tests probably do not leave the test JVM in an unclean state, but if other tests are run concurrently with the JcToolsSecurityManagerTest then it will get ArrayBlockingQueue instead of JcTools queue (a bit randomly since test execution parallelism/ordering is not deterministic) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of small comments but looks good otherwise
...haded-deps/src/test/java/io/opentelemetry/sdk/trace/internal/JcToolsSecurityManagerTest.java
Show resolved
Hide resolved
...haded-deps/src/test/java/io/opentelemetry/sdk/trace/internal/JcToolsSecurityManagerTest.java
Outdated
Show resolved
Hide resolved
.../src/test/java/io/opentelemetry/sdk/trace/internal/SunMiscProhibitedSecurityManagerTest.java
Outdated
Show resolved
Hide resolved
.../src/test/java/io/opentelemetry/sdk/trace/internal/SunMiscProhibitedSecurityManagerTest.java
Outdated
Show resolved
Hide resolved
.../src/test/java/io/opentelemetry/sdk/trace/internal/SunMiscProhibitedSecurityManagerTest.java
Outdated
Show resolved
Hide resolved
is this mergeable? |
the only thing I am afraid of is that it will degrade performance in these environments without any warning so perhaps a warning should be logged |
I'm in favor of logging a warning though. Should make sure its only logged once, rather than each time a queue is created. |
Warning added and duplicates mostly avoided (could still happen when creating many queues concurrently) Rebased. Good to merge? |
e07af3e
to
ed5c0d8
Compare
sdk/trace-shaded-deps/src/main/java/io/opentelemetry/sdk/trace/internal/JcTools.java
Outdated
Show resolved
Hide resolved
...haded-deps/src/test/java/io/opentelemetry/sdk/trace/internal/JcToolsSecurityManagerTest.java
Show resolved
Hide resolved
Some applications run under strict java.security permissions which do not allow access to sun.misc.Unsafe. BatchSpanProcessor uses Unsafe via jctools, but has a fallback to ArrayBlockingQueue. Extending that fallback rule to cover java security exceptions as well.
…pen-telemetry#4902) Some applications run under strict java.security permissions which do not allow access to sun.misc.Unsafe. BatchSpanProcessor uses Unsafe via jctools, but has a fallback to ArrayBlockingQueue. Extending that fallback rule to cover java security exceptions as well. Co-authored-by: Jack Berg <jberg@newrelic.com>
Some applications run under strict java.security permissions which do not allow access to sun.misc.Unsafe.
BatchSpanProcessor uses Unsafe via jctools, but has a fallback to ArrayBlockingQueue. Extending that fallback rule to cover java security exceptions as well.
Since the entire java security manager is marked for deprecation in future java versions, I went with string-matching on the root cause message, which removes deprecation warnings when building with newer java but still does the job in those versions which use java.security policies.