Skip to content

Conversation

@emerkle826
Copy link

No description provided.

});
}

private long convertToTimeUnit(double value) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will, if we decide to bring the config setting back.

public void bindTo(@NonNull MeterRegistry meterRegistry) {
Assert.isTrue(this.session.getMetrics().isPresent(), "Metrics on the CqlSession needs to be present");

this.session.getMetrics().get().getRegistry().getMetrics().forEach((name, m) -> {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to validate if we are correctly registering different types of metrics, we should create an IT test that checks at least one metric of every type. Maybe you could follow this test:
https://github.com/riptano/java-driver-spring/blob/master/integration-tests/src/test/java/com/datastax/oss/spring/configuration/exampletests/CassandraMetricsMicrometerIT.java
It iterates over all metrics and validates that they are registered properly. I was able to catch some bugs when implementing original version using this test.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added some more example metrics to the test here.

@emerkle826
Copy link
Author

@adutra and @tomekl007 I've added a few more tests and I think I've addressed the feedback. I'd appreciate one last quick check when you have a chance and then I'll move the PR to Spring's repo.

* on the classpath.
*/
@Test
void cassandraInstrumentationIsDisabledIfDriverClassesNotOnClasspath() {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should also test the case when MetricsRegistry AND CqlSession is not on the classpath. In that case the MeterRegistry.getBean should return null.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't make sense to try to test with CqlSession filtered from the classpath. The ApplicationContextRunner tries to run with CassandraMetricsAutoConfiguration, which requires a CqlSession bean. If CqlSession isn't on the classpath, trying to spin up a context with CassandraMetricsAutoConfiguration will throw an exception indicating it can't find a required bean.

I can change the test so that it removes MetricRegistry from the classpath, but I'm mocking the CqlSession bean with a MetricRegistry since the tests don't have a fully initialized CqlSession bean with metrics configuration. I don't think removing MetricRegistry from the classpath at this point will prevent the metrics from being bound to the Micrometer MeterRegistry.

Or am I missing something?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't make sense to try to test with CqlSession filtered from the classpath. The ApplicationContextRunner tries to run with CassandraMetricsAutoConfiguration, which requires a CqlSession bean. If CqlSession isn't on the classpath, trying to spin up a context with CassandraMetricsAutoConfiguration will throw an exception indicating it can't find a required bean.

It shouldn't throw an exception, it should instead not be executed as part of the configuration process, since that class has a @ConditionalOnClass({ MeterRegistry.class, CqlSession.class }) annotation.

This specific test does exactly that: it includes CassandraMetricsAutoConfiguration in the context, but excludes CqlSession from the classpath, to emulate the situation where the driver is not on the classpath.

I think what @tomekl007 wants is just another test similar to this one, but in which MeterRegistry would also be absent from the classpath, to emulate the situation where the user has excluded Micrometer and the driver from the classpath.

I personally don't think that this is a common situation, but imo it doesn't hurt to add a test for that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand the intent. But I'm seeing the exception when I run the tests if I don't provide a CqlSession bean to the test's ApplicationContextRunner, i.e.

this.contextRunner.withBean(CqlSession.class, () -> mockSession(true))

If I omit the bean, I get a NoSuchBeanDefinitionException with

No qualifying bean of type 'com.datastax.oss.driver.api.core.CqlSession' available.

Does it make sense to create the context with the mocked bean, but test without CqlSession on the classpath?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I see the problem....

Copy link
Author

@emerkle826 emerkle826 May 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, with the latest changes, I can spin up the context with CqlSession and MetricRegistry missing from the classpath. The Micrometer metrics are indeed disabled, however the Micrometer MeterRegisrty is not null, it simply has no meters in its map.

void autoConfiguredCassandraIsInstrumented() {
this.contextRunner.withBean(CqlSession.class, () -> mockSession(true)).run((context) -> {
MeterRegistry registry = context.getBean(MeterRegistry.class);
// Assert a typical Driver Meter metric
Copy link

@tomekl007 tomekl007 May 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can we extract assertions of metrics to separate methods for readability? i.e:
https://github.com/datastax/spring-boot/pull/2/files#diff-8991f02ba760e2c1590560601a62f5a1R59-R61
to assertMeterMetric(), then assertGaugeMetric(), etc

@adutra
Copy link

adutra commented May 31, 2020

Official PR opened here: spring-projects#21624.

philwebb and others added 27 commits August 17, 2020 16:17
Rename `CompositeMeterRegistryAutoConfiguration` to
`MeterRegistryAutoConfiguration` since it can also create non-composite
registries.

Closes spring-projectsgh-22988
Create a new `JarFileWrapper` class so that we can wrap and existing
`JarFile` and offer a version that can be safely closed.

Prior to this commit, we provided wrapper functionality in the `JarFile`
class itself. Unfortunately, because we override `close` and also create
a lot of wrappers this caused memory issues when running on Java 11.

With Java 11 `java.util.zip.ZipFile` class uses `FinalizableResource`
for any implementation that overrides `close()`. This means that any
wrapper classes will not be garbage collected until the JVM finalizer
thread runs.

Closes spring-projectsgh-22991
This commit adds a check to the `layertools extract` command to
ensure that the jar file being processed is readable and has a
valid directory.

Fixes spring-projectsgh-22993
Refine method visibility in an attempt to fix test issues on Java 11+.

See spring-projectsgh-22991
Remove Mockto from JarFileWrapperTests since it seems to be failing on
later versions of Java.

See spring-projectsgh-22991
Update `Repackager` to ensure that `getLayout` is called before we
backup the source file. This restores earlier behavior that some
custom `ModuleFactory` implementations were relying on.

Closes spring-projectsgh-22995
* pr/23002:
  Mention correct JUnit 5 annotations in Kotlin testing section

Closes spring-projectsgh-23002
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.