Support the JDK's ThreadLocalRandom #1052
Merged
Conversation
This file contains 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
arteam
force-pushed
the
support_jdk_thread_local_random
branch
4 times, most recently
from
562aeff to
2f129eb
Compare
|
I dug out an old dusty JRE6 build (Travis doesn't support it anymore), and the tests passed locally. |
|
@dropwizard/dropwizard-metrics Could someone please review this? |
arteam
commented
Feb 2, 2017
| @@ -95,7 +95,7 @@ public void update(long value, long timestamp) { | |||
| try { | |||
| final double itemWeight = weight(timestamp - startTime); | |||
| final WeightedSample sample = new WeightedSample(value, itemWeight); | |||
| final double priority = itemWeight / ThreadLocalRandom.current().nextDouble(); | |||
| final double priority = itemWeight / ThreadLocalRandomFactory.current().nextDouble(); | |||
There was a problem hiding this comment.
Alternate approach is to switch to Java 7, but that would break Java 6 - compatibility, which I think it's not desirable for a maintenance release .
There was a problem hiding this comment.
Agreed, we could do that for 3.2
arteam
force-pushed
the
support_jdk_thread_local_random
branch
from
2f129eb to
284ff93
Compare
arteam
force-pushed
the
support_jdk_thread_local_random
branch
from
284ff93 to
7154ab4
Compare
ryantenney
reviewed
Feb 4, 2017
| * By default it tries to use the JDK's implementation and fallbacks to the internal | ||
| * one if the JDK doesn't provide any. | ||
| */ | ||
| class ThreadLocalRandomFactory { |
There was a problem hiding this comment.
I think this should be ThreadLocalRandomProxy instead.
There was a problem hiding this comment.
This is a also a good name.
arteam
force-pushed
the
support_jdk_thread_local_random
branch
from
7154ab4 to
752d244
Compare
ryantenney
reviewed
Feb 4, 2017
| */ | ||
| private static class JdkDelegate { | ||
|
|
||
| private static Random get() { |
There was a problem hiding this comment.
Lets rename this to current, just to be consistent.
arteam
force-pushed
the
support_jdk_thread_local_random
branch
from
752d244 to
406d280
Compare
|
This looks great. The only thing I was thinking about was trying to avoid the branch per call by making the JdkDelegate an instance class, creating a new delegate class for our backfill ThreadLocalRandom, and an interface that defines just the |
Add a proxy which provides a ThreadLocalRandom implementation depending on its availability in runtime. If the JDK provides ThreadLocalRandom, use it. Otherwise, fallback to the internal implementation.
arteam
force-pushed
the
support_jdk_thread_local_random
branch
from
406d280 to
4487e8b
Compare
|
That's fantastic! Thank you! You've tested this in JDK 6? I'm curious because just by looking at it, I'm not sure whether NoClassDefFound error would be thrown during the instantiation of JdkProvider, or if it would be thrown while calling |
|
Yes, I've run the suite in JDK6. If I add a I suppose the exception is thrown when the |
|
Merge away! |
|
When is this fix release into maven repository? |
|
I think we could make a release this week. Seems like nothing remains in the queue for 3.1.3. |
arteam
added a commit
that referenced
this pull request
Feb 15, 2017
* Support for publishing metrics of BigInteger and BigDecimal type * Update third-party.rst New reporter - metrics-munin-reporter * Add links to more third party libs * Update third-party to include metrics-circonus * Fix spelling in core.rst * #814 always close socket (cherry picked from commit 2762ce5) * Revert "Add log4j2 xml-based config support" This reverts commit 6667014. * Revert "Added log4j2 InstrumentedAppender xml support to docs" This reverts commit 26c4cd2. * Revert "Fix javadoc link" This reverts commit 28e6556. * Revert "Add CPU profiling support to the AdminServlet (fixes #927)" This reverts commit bbb52c1. * Revert "Support for publishing metrics of BigInteger and BigDecimal type" This reverts commit 7cfc23c. * Suppress all kinds of Exceptions raised by report() (#1049) (#1056) * Support the JDK's ThreadLocalRandom (#1052) Add a proxy which provides a ThreadLocalRandom implementation depending on its availability in runtime. If the JDK provides ThreadLocalRandom, use it. Otherwise, fallback to the internal implementation. * Support JDK's LongAdder (#1055) * Support the JDK's LongAdder Add an ability to use the JDK's implementation if it's available in the runtime. Use a proxy for creating LongAdders which tries to use the JDK's implementation and fallbacks to the internal one if the JDK doesn't provide any. Unfortunatelly, `LongAdder`s don't have a common interface, therefore we introduce `LongAdderAdapter` as a common interface for `LongAdder`s. It will be used in other components as an interface, but a concrete implementation of it will be created by `LongAdderProxy`. This pattern allows to us to still run code in the JRE, but enjoy the benefits of the stock `LongAdder` in modern JDKs (less bugs, better performance). * Run tests only on JDK8 We need a compile dependency on LongAdders which is not available in JDK7. * Retry DNS lookups (#1064) Do retry DNS lookups, which are just done in the constructor of InetSocketAddress. Reason might be that in some environments DNS is very dynamic and thus a name might be sometimes resolveable and sometimes not. The way this is currently implemented the InetSocketAddress is always cached, which in itself caches the return value of the last DNS lookup, even if that failed. * Backport rescale bug (#1046) * Added ExponentiallyDecayingReservoir test illustrating the rescale race condition. (cherry picked from commit d9af3c1) * Fixed the race condition in ExponentiallyDecayingReservoir's rescale method. (cherry picked from commit b022f04)
|
Ryan, as you wondered : "I'm not sure whether NoClassDefFound error would be thrown during the instantiation of JdkProvider, or if it would be thrown while calling JdkProvider.current", in fact, testing 3.1.4, on Weblogic 10.3 and Oracle JDK 6, the exception is thrown only when JdkProvider.current is called, not when JdkProvider constructor is called, so 3.1.4 is KO. Curiously, on Tomcat 7 and the same Oracle JDK 6, the exception is thrown when the JdkProvider constructor is called. I made a pull request for my tested workaround (#1129). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Add a factory which provides a ThreadLocalRandom implementation depending on its availability in runtime. If the JDK provides ThreadLocalRandom, use it. Otherwise, fallback to the internal implementation.