Support JDK's LongAdder #1055
Support JDK's LongAdder #1055
Conversation
|
@ryantenney did something similar for the 4.0 branch in #876 |
|
This also should fix |
|
Bummer. The build can't compiled on Travis on JDK 7, because LongAdder doesn't exist in the JDK. @dropwizard/dropwizard-metrics I'm wondering if we can remove it (JDK 6/7 will be still supported in runtime). |
arteam
force-pushed
the
long_adder_delegate
branch
from
8745f48
to
66b006b
Compare
|
You've got the right idea, but what I'd recommend is adding a metrics-java8 module that is compiled using Java 8 (and is ignored if the compiler is <8). Then if someone wants to use the native longadder, they can import that module. I went looking for an old branch where I started to do just that, but I can't find it. |
|
Thanks for the feedback! I got your point, but I think it would be better to implement this feature in a maintenance release without additional modules. The internal |
arteam
force-pushed
the
long_adder_delegate
branch
2 times, most recently
from
bd28f40
to
71656f6
Compare
|
I've updated the pull request to align the implementation with the |
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).
arteam
force-pushed
the
long_adder_delegate
branch
2 times, most recently
from
e8a8754
to
d9a82a2
Compare
We need a compile dependency on LongAdders which is not available in JDK7.
|
Looks good to me, want me to merge this in @ryantenney ? |
|
@jplock go for it! |
* 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)
Add an ability to use the JDK's implementation if it's available in runtime. Add a factory for creating LongAdders which tries to use the JDK's implementation and fallbacks to the internal one if the JDK doesn't provide any. Unfortunately, LongAdders don't have a common interface, therefore we introduce
LongAdderAdapter. It will be used in other components as an interface, a concrete implementation of it will be created byLongAdderFactory.