These are chat archives for spring-cloud/spring-cloud

16th
Feb 2018
Mike Liu
@mikexliu
Feb 16 2018 02:37

hi, i was looking through the source code for spring cloud config server because i was having some performance issues and i noticed that that when a client gets the configurations, the server creates a new spring context to generate the configurations? (https://github.com/spring-cloud/spring-cloud-config/blob/master/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/environment/NativeEnvironmentRepository.java#L137)

Is there a reason for this (besides reusing code)? the spring context creation seems very heavy (relatively), but it was enough to hang the cpu and then block any remaining threads for the request thread pool

Dave Syer
@dsyer
Feb 16 2018 08:07
It's not really heavy at all in normal circumstances. The CPU hanging sounds like some other issue to me (there isn't really even any CPU-intensive work done by Spring).
Dave Syer
@dsyer
Feb 16 2018 08:16
It's quite likely that threads are blocked (there are explicit synchronizations in there to protect the state of the data in the git working directory). And there is plenty of IO (git). But I doubt there is any CPU work, unless you added it somehow.
All of that will be a lot more expensive than anything Spring is doing to create a tiny application context.
Michael Stummvoll
@Stummi
Feb 16 2018 09:06
what is the preferred way here to share about 50 lines of code snippet? Direct Paste or Gist? I am kinda new to gitter
Dave Syer
@dsyer
Feb 16 2018 09:24
50 is probably fine to paste here as long as you format it. Read the markdown cheat sheet.
gitter rolls up longer snippets anyway
Michael Stummvoll
@Stummi
Feb 16 2018 09:24
fine
Trying to reduce the issue right now, maybe it will be fewer lines. Seems like I have strange problem with an @FeignClient which seems to only appear when I use the local server and have a @RequestMapping annotation on interface level
Michael Stummvoll
@Stummi
Feb 16 2018 09:30

Okay, heres the code:

package org.stummi.feigndemo;

import com.netflix.loadbalancer.Server;
import com.netflix.loadbalancer.ServerList;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.cloud.netflix.feign.EnableFeignClients;
import org.springframework.cloud.netflix.feign.FeignClient;
import org.springframework.cloud.netflix.ribbon.RibbonClient;
import org.springframework.cloud.netflix.ribbon.StaticServerList;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

public class Main {
  @Configuration
  @EnableAutoConfiguration
  @RestController
  @EnableFeignClients(clients = { TestClient.class })
  @RibbonClient(name = "localapp", configuration = LocalRibbonClientConfiguration.class)
  static class Application {
    @RequestMapping("/hello")
    public String hello() {
      return "hello";
    }
  }

  @Configuration
  static class LocalRibbonClientConfiguration {
    @Bean
    public ServerList<Server> ribbonServerList() {
      return new StaticServerList<>(new Server("localhost", 8080));
    }
  }

  @FeignClient(name = "localapp")
  //@RequestMapping(method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
  static interface TestClient {
    @RequestMapping(value = "/hello")
    public String hello();
  }

  public static void main(String[] args) throws InterruptedException {
    TestClient testClient = SpringApplication.run(Application.class, args)
        .getBean(TestClient.class);
    System.out.println(" --> " + testClient.hello());
  }
}

using spring-boot 1.5.10.RELEASE, and spring-cloud Edgware.SR1

It workes fine this way, however when I add the @RequestMapping to the FeignClient I get a strange behavior (log exploding with SocketTimeoutException's in no time. Looks like theres a very small Timeout used somehwere internal?)
also when I cosume any other server than the local one, it works fine.
Dave Syer
@dsyer
Feb 16 2018 09:34
I don't think @RequestMapping at the interface level is a good idea.
Michael Stummvoll
@Stummi
Feb 16 2018 09:34
So the issue is the combination of the @RequestMapping beeing on interface level and the Feign target being the local server. I hope you understand my confusion
Dave Syer
@dsyer
Feb 16 2018 09:34
I'm not sure it is really supported.
It certainly would be confusing for Spring.
It thinks you asked it to create a request mapping for incoming HTTP requests
Michael Stummvoll
@Stummi
Feb 16 2018 09:35
@dsyer well, "it worked fine" without that strange edgecase. So I assumed its supported. I hoped I can avoid some duplications of requestMethod = GET and produces = ... this way
Dave Syer
@dsyer
Feb 16 2018 09:38
:shrug:
Michael Stummvoll
@Stummi
Feb 16 2018 09:46
Okay. I just thought the class level annotation propagates into the methods, similar as for @Controller classes. I will avoid using this annotation. Thanks
Michael Stummvoll
@Stummi
Feb 16 2018 12:12
what bean can I use to resolve a ribbon key automatically? I tried autowirng ILoadBalancer and LoadBalancerContext, which does not seem to be in the CP
s/CP/Context
and, with automatically I meant programatically
Knut Schleßelmann
@kschlesselmann
Feb 16 2018 12:31
Is it somehow possible to achieve kafkas exactly once semantics if your stream processor writes to a database during processing and ou want to have processed events in the database exactly once too?
sur7725
@sur7725
Feb 16 2018 12:48
Is there any update please...I got stuck

Discovery client name is not resolved in WebResource Object of RestClient. Whereas it is working fine with RestTemplate on registered discovery client name.

We are getting Exception com.sun.jersey.api.client.ClientHandlerException Occured during REST call.

com.sun.jersey.api.client.ClientHandlerException: java.net.UnknownHostException:. Please help...

David Welch
@dwelch2344
Feb 16 2018 18:42
question SC Consul: the ScheduledThreadPoolExecutor doesn't seem to be shutting down when we destroy our app context. Is there a hook or something we need to register?

Looks related to the ConsulBinderConfiguration -> ConsulBinder -> ConsulInboundMessageProducer creating it's own instance internally and not getting called. We're not running in a traditional SpringApplication so probably missing something that de-registers him.

@spencergibb seeing your name on a lot of this. any thoughts?

David Welch
@dwelch2344
Feb 16 2018 19:32
Nope, false alarm. It's TtlScheduler creates a scheduler internally and has no way to shut him down – will open an issue for it (and hopefully a PR)
Spencer Gibb
@spencergibb
Feb 16 2018 19:38
thanks @dwelch2344