Skip to content
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

brave.mysql8 Tracing stuck on startup when running a Spring Boot + Wavefront application #34

Open
odedia opened this issue Jul 27, 2020 · 3 comments

Comments

@odedia
Copy link

odedia commented Jul 27, 2020

Describe the Bug

When a Spring Boot application contains brave mysql8 tracing plus Spring Cloud Sleuth and Wavefront dependencies, it causes the application to freeze on startup after the HikariCP pool is being created. Specifically at line 52 of TracingQueryInterceptor.

Steps to Reproduce

Steps to reproduce the behavior:
Clone this simple repo: https://github.com/odedia/todo-service

Start a local mariabdb docker container:

docker run --name mariadb -e MYSQL_ROOT_PASSWORD=unix11 -e MYSQL_DATABASE=my_database -p 3306:3306 mariadb:10.3.23

Run the application using:

SPRING_PROFILES_ACTIVE=local mvn spring-boot:run

The app will boot successfully.

Comment line 7 and uncomment line 8 in application-local.properties to add the mysql tracing interceptor:

# spring.datasource.url: jdbc:mysql://localhost:3306/my_database?user=root&password=unix11&useSSL=false
spring.datasource.url: jdbc:mysql://localhost:3306/my_database?user=root&password=unix11&useSSL=false&queryInterceptors=brave.mysql8.TracingQueryInterceptor&exceptionInterceptors=brave.mysql8.TracingExceptionInterceptor&zipkinServiceName=tac_db

Expected Behaviour

App should still boot, however in practice it is now stuck on startup after line 52 of TracingQueryInterceptor.

@codefromthecrypt codefromthecrypt transferred this issue from openzipkin/brave Jul 28, 2020
@codefromthecrypt
Copy link
Member

It is unlikely that the solution to this will end up in this repo. as brave implements a mysql interceptor and isn't doing anything around connection management or configuration.

This sounds like a configuration lock. Did you try asking on https://gitter.im/spring-cloud/spring-cloud-sleuth maybe a thread dump for the hung process will help proceed.

@odedia
Copy link
Author

odedia commented Jul 30, 2020

Found the root cause - the startup is stuck when no default Sampler bean is defined. It occurs in the isSampled() method. Fixed by adding the following to a @Configuration class (for example):

	@Bean
	public Sampler defaultSampler() {
		return Sampler.ALWAYS_SAMPLE;
	}

@codefromthecrypt
Copy link
Member

codefromthecrypt commented Jul 30, 2020 via email

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

No branches or pull requests

2 participants