Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:50

    spring-buildmaster on gh-pages

    Sync docs from 2.0.x to gh-pages (compare)

  • 00:41

    spring-buildmaster on gh-pages

    Sync docs from 2.1.x to gh-pages (compare)

  • 00:40

    spring-buildmaster on gh-pages

    Sync docs from 1.3.x to gh-pages (compare)

  • Aug 20 08:46
    marcingrzejszczak commented #1426
  • Aug 20 08:44
    matus753 commented #1426
  • Aug 20 08:44
    matus753 commented #1426
  • Aug 20 01:50

    spring-buildmaster on gh-pages

    Sync docs from 2.0.x to gh-pages (compare)

  • Aug 20 00:41

    spring-buildmaster on gh-pages

    Sync docs from 2.1.x to gh-pages (compare)

  • Aug 20 00:40

    spring-buildmaster on gh-pages

    Sync docs from 1.3.x to gh-pages (compare)

  • Aug 19 12:36
    olegz commented #1426
  • Aug 19 12:12
    spring-issuemaster unlabeled #1426
  • Aug 19 12:12
    spring-issuemaster labeled #1426
  • Aug 19 12:12
    marcingrzejszczak commented #1426
  • Aug 19 12:11
    matus753 commented #1426
  • Aug 19 10:14
    adriancole commented #1427
  • Aug 19 09:19
    Liodene commented #1427
  • Aug 19 09:16
    Liodene commented #1427
  • Aug 19 09:16
    marcingrzejszczak commented #1427
  • Aug 19 09:15
    Liodene commented #1427
  • Aug 19 09:02
    adriancole commented #1427
pzma
@pzma
When I look at the outgoing requests I can see my baggage entries in the request as headers, and I am setting entries with extrafieldpropagation.set(key,value)
I am able to also access the baggage in downstream services
I am on boot 2.1 and Greenwich
Marcin Grzejszczak
@marcingrzejszczak
Can you create a sample?
Rafael Kansy
@Pirat83
But I simply am not able to find the difference and make the BeanFactory call the pointcuts from org.springframework.cloud.sleuth.instrument.messaging.SleuthKafkaAspect
Did somebody of you already fixed such issues?
just in case somebody asks
we have solved this issue
Marcin Grzejszczak
@marcingrzejszczak
can you describe how>
Rafael Kansy
@Pirat83
the problem was that we have implemented a custom AsyncConfigurerSupport with an custom java.util.concurrent.Executor
Sleuth does builds its own java.util.concurrent.Executor in org.springframework.cloud.sleuth.instrument.async.AsyncDefaultAutoConfiguration and customizes it in org.springframework.cloud.sleuth.instrument.async.LazyTraceAsyncCustomizer
Marcin Grzejszczak
@marcingrzejszczak
Ah you've injected via your class right?
Instead of an interface?
Rafael Kansy
@Pirat83
so if you implement the method org.springframework.scheduling.annotation.AsyncConfigurer#getAsyncExecutor then the KafkaTemplate was not instrumented and all ``Async``` operations have been executed synchronously. Which is really bad... in our case.
Marcin Grzejszczak
@marcingrzejszczak
Sounds bad indeed
Rafael Kansy
@Pirat83
For now, we have implemented org.springframework.scheduling.annotation.AsyncConfigurer without implementing org.springframework.scheduling.annotation.AsyncConfigurer#getAsyncExecutor
if we want to define a custom async thread executor then we will define a @Bean named taskExecutor
like described in the JavaDoc of org.springframework.cloud.sleuth.instrument.async.AsyncDefaultAutoConfiguration.DefaultAsyncConfigurerSupport#getDefaultExecutor
I do not know yet which side effects this will have in our setup but for now, we can live with this setup.
It is also important to define the custom AsyncExceptionHandler asyncExceptionHandler as @Lazy
because we had cyclic dependencies while bootstrapping the Beanfactory. Which was part of the issue.
really hard to detect, but now everything works fine
Rafael Kansy
@Pirat83
I have written this JavaDoc in our AsyncConfiguration:
import de.id.dataimport.sink.service.AsyncExceptionHandler;
import org.springframework.aop.interceptor.AsyncUncaughtExceptionHandler;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Lazy;
import org.springframework.scheduling.annotation.AsyncConfigurer;
import org.springframework.scheduling.annotation.EnableAsync;

import java.util.concurrent.Executor;

/**
 * Dear developer please read this before you modify this class.
 *
 * it is important to NOT define a custom {@link Executor} in
 * {@link org.springframework.scheduling.annotation.AsyncConfigurer#getAsyncExecutor()}.
 * <p>
 * Spring cloud sleuth creates its own {@link Executor} in
 * {@link org.springframework.cloud.sleuth.instrument.async.AsyncDefaultAutoConfiguration.DefaultAsyncConfigurerSupport}.
 * This {@link Executor} is then customized in {@link org.springframework.cloud.sleuth.instrument.async.LazyTraceAsyncCustomizer}.
 * <p>
 * If you implement the {@link org.springframework.scheduling.annotation.AsyncConfigurer#getAsyncExecutor()} method
 * we will lose {@link org.springframework.scheduling.annotation.Async} support and all methods annotated with
 * {@link org.springframework.scheduling.annotation.Async} will be executed in the calling thread pool
 * (which is a really bad situation - it disables asynchronous behavior that is totally required)
 * If you really need to create your own {@link Executor} try to override the default {@link Executor}
 * with the bean name {@code taskExecutor}.
 * <p>
 * It is also crucial to define the {@link AsyncExceptionHandler} as {@link Lazy}, because we have cyclic dependencies in
 * our {@link org.springframework.beans.factory.BeanFactory} and if you do not so Spring can not apply all
 * {@link org.springframework.beans.factory.config.BeanPostProcessor} executions to i.e
 * {@link org.springframework.kafka.core.KafkaTemplate}. This leads to lost {@link brave.Span}s.
 */
@Configuration
@EnableAsync
public class AsyncConfiguration implements AsyncConfigurer {

  private AsyncExceptionHandler asyncExceptionHandler;

  public AsyncConfiguration(@Lazy AsyncExceptionHandler asyncExceptionHandler) {
    this.asyncExceptionHandler = asyncExceptionHandler;
  }

  @Override
  public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
    return asyncExceptionHandler;
  }
}
Marcin Grzejszczak
@marcingrzejszczak
Do you think that we can do sth in sleuth to improve this?
Rafael Kansy
@Pirat83
Well the biggest issue is IMHO that we lose the @Async execution and developers with not so much experience may not realize it.
it is also difficult to test if a statement is executed asynchronously on the correct thread executor.
So one thing that would help very much (and I do not know how to achieve it) would be to fail fast if one Component (i.e the KafkaTemplate, the RabittTemplate or the RestTemplate) runs without the Brave Instrumentation. Or at least write some warnings in the log file.
Rafael Kansy
@Pirat83
Another thing is to "resolve" cyclic dependencies when bootstrapping the application.
So the @Lazy annotation solved most of our issues
We just see an info message in the log that some beans can not be used with autoproxying. And a lot of StackOverflow that we do not have to worry about the Bean X of type Y is not eligible for getting processed by all BeanPostProcessors. But if the i.e the KafkaTemplate is one of the beans where autoproxying can not be applied we have a very hard to debug problem.
Rafael Kansy
@Pirat83
so at least a warning in the log would be very good. Improving the documentation would be also very good. Just one paragraph: "If you see the log message Bean X of type Y is not eligible for getting processed by all BeanPostProcessors and bean X is your i.e KafkaTemplate then you will lose trace propagation across the services.
Our services are also not very complicated. They have a org.springframework.boot:spring-boot-starter-web. A @RestController accepts a simple POSTrequest. Does some work in an @Async annotated @Service method. And sends the result to Kafka by using the @KafkaTemplate.
It is hard to believe that such a simple use case can add cyclic dependencies to the beans in the Beanfactory. And BeanPostProcessors can not be applied to some beans.
Rafael Kansy
@Pirat83
Maybe picking up a user-defined Executor in org.springframework.scheduling.annotation.AsyncConfigurer#getAsyncExecutor and then applying the sleuth instrumentation could be also a possible way to go.
Marcin Grzejszczak
@marcingrzejszczak
can you create an issue and a sample that reproduces the problem?
Rafael Kansy
@Pirat83
Maybe on weekend... I can not promise...
Marcin Grzejszczak
@marcingrzejszczak
:+1:
Sinchana94
@Sinchana94
@shakuzen reason being , have to run zipkin server registering to eureka server and also I dont need links to twitter, glitter that we have in Lens UI section
Sinchana94
@Sinchana94
@shakuzen tried the metrics endpoint and getting the response as below, {"counter.zipkin_collector.messages.http":0.0,"counter.zipkin_collector.spans_dropped.http":0.0,"gauge.zipkin_collector.message_bytes.http":0.0,"counter.zipkin_collector.bytes.http":0.0,"gauge.zipkin_collector.message_spans.http":0.0,"counter.zipkin_collector.spans.http":0.0,"counter.zipkin_collector.messages_dropped.http":0.0}
Tommy Ludwig
@shakuzen
@Sinchana94 we don't support custom Zipkin Server builds because there's too many variables to debug. there's some information in openzipkin/zipkin#1870 about how you could get Eureka working with the standard Zipkin Server without building your own.
since all the counters are zero, it looks like the zipkin server isn't receiving any trace data, though
Sinchana94
@Sinchana94
@shakuzen okay but from client side exportable is showing as true, that means it has travelled to zipkin server right?
@shakuzen thank you, how about the link for twitter and glitter we have in LensUI, that would still be there isn't it?
Tommy Ludwig
@shakuzen
exportable being true means that the span should be reported. it may be failing to report. you can check the client's zipkin reporter metrics to see. maybe the configured zipkin server isn't correct or something.
Tommy Ludwig
@shakuzen
yes, the links to twitter/gitter are there in the UI. I think providing links on where to get help with the tool you're using is a fairly normal thing in most open source tools out there. for example, Grafana includes similar links in its UI. if you have feedback on this in general, you can let the Zipkin team know in https://gitter.im/openzipkin/zipkin
Sinchana94
@Sinchana94
@shakuzen I used the latest zipkin server you provided(https://zipkin.io/pages/quickstart.html) and ran in local and configured client application with the local zipkin url, can you share the url to check from client side?
@shakuzen yeah thanks for the insight , I see your point in having those links
Tommy Ludwig
@shakuzen
does the client have Actuator? I don't remember the exact metric name but you can see all metrics from /actuator/metrics if you have Actuator on the classpath.
Sinchana94
@Sinchana94
yes it has actuator, let me try