0

I am trying to configure SVN to fetch my configuration using Spring Cloud Config Server which is discoverable by a Eureka Server. The first time the config server registers as "UP" in Eureka but as soon as I bring it down and start it up again I am seeing it in "DOWN" status in Eureka.

I used this example as reference as there aren't much documentation available for using svn as a source for your configuration

Any help would be really appreciated:

POM dependency - pertaining to config server

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>Camden.SR4</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

<dependency>
    <groupId>org.tmatesoft.svnkit</groupId>
    <artifactId>svnkit</artifactId>
</dependency>

Config Server - bootstrap.yml

spring:
  application:
    name: config-server
  profiles:
    active: subversion

Config Server - application.yml

 spring:
  cloud:
    config:
      server:
        svn:
          uri: <my svn repo>
          username: username
          password: password
          basedir: <file system path where the repo would be checked out>
          default-label: <my branch path where the actual config file resides>

Below is what I see in my log console

2017-02-07 14:41:21.263  INFO 28776 --- [           main] com.netflix.discovery.DiscoveryClient    : Saw local status change event StatusChangeEvent [timestamp=1486507281263, current=UP, previous=STARTING]
2017-02-07 14:41:21.266  INFO 28776 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_CONFIG-SERVER/<machine-name>:config-server:8100: registering service...
2017-02-07 14:41:21.696  INFO 28776 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8100 (http)
2017-02-07 14:41:21.699  INFO 28776 --- [           main] c.n.e.EurekaDiscoveryClientConfiguration : Updating port to 8100
2017-02-07 14:41:21.710  INFO 28776 --- [           main] c.s.s.s.c.a.ConfigServerApplication      : Started ConfigServerApplication in 12.477 seconds (JVM running for 20.423)
2017-02-07 14:41:21.881  INFO 28776 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_CONFIG-SERVER/<machine-name>:config-server:8100 - registration status: 204
2017-02-07 14:41:22.263 DEBUG 28776 --- [nfoReplicator-0] o.s.c.c.s.e.SvnKitEnvironmentRepository  : Repo already checked out - updating instead.
2017-02-07 14:41:25.106  WARN 28776 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient    : Saw local status change event StatusChangeEvent [timestamp=1486507285106, current=DOWN, previous=UP]
2017-02-07 14:41:25.106  WARN 28776 --- [nfoReplicator-0] c.n.discovery.InstanceInfoReplicator     : Ignoring onDemand update due to rate limiter
2017-02-07 14:41:25.106  INFO 28776 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_CONFIG-SERVER/<machine-name>:config-server:8100: registering service...
2017-02-07 14:41:25.114  INFO 28776 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_CONFIG-SERVER/<machine-name>:config-server:8100 - registration status: 204
2017-02-07 14:41:51.214  INFO 28776 --- [freshExecutor-0] com.netflix.discovery.DiscoveryClient    : Disable delta property : false
2017-02-07 14:41:51.216  INFO 28776 --- [freshExecutor-0] com.netflix.discovery.DiscoveryClient    : Single vip registry refresh property : null
2017-02-07 14:41:51.217  INFO 28776 --- [freshExecutor-0] com.netflix.discovery.DiscoveryClient    : Force full registry fetch : false
2017-02-07 14:41:51.218  INFO 28776 --- [freshExecutor-0] com.netflix.discovery.DiscoveryClient    : Application is null : false
2017-02-07 14:41:51.219  INFO 28776 --- [freshExecutor-0] com.netflix.discovery.DiscoveryClient    : Registered Applications size is zero : true
2017-02-07 14:41:51.220  INFO 28776 --- [freshExecutor-0] com.netflix.discovery.DiscoveryClient    : Application version is -1: false
2017-02-07 14:41:51.221  INFO 28776 --- [freshExecutor-0] com.netflix.discovery.DiscoveryClient    : Getting all instance registry info from the eureka server
2017-02-07 14:41:51.251  INFO 28776 --- [freshExecutor-0] com.netflix.discovery.DiscoveryClient    : The response status is 200
2017-02-07 14:41:55.121 DEBUG 28776 --- [nfoReplicator-0] o.s.c.c.s.e.SvnKitEnvironmentRepository  : Repo already checked out - updating instead.
2017-02-07 14:42:27.122 DEBUG 28776 --- [nfoReplicator-0] o.s.c.c.s.e.SvnKitEnvironmentRepository  : Repo already checked out - updating instead.
2017-02-07 14:42:59.114 DEBUG 28776 --- [nfoReplicator-0] o.s.c.c.s.e.SvnKitEnvironmentRepository  : Repo already checked out - updating instead.
2017-02-07 14:43:31.107 DEBUG 28776 --- [nfoReplicator-0] o.s.c.c.s.e.SvnKitEnvironmentRepository  : Repo already checked out - updating instead.
2017-02-07 14:44:03.106 DEBUG 28776 --- [nfoReplicator-0] o.s.c.c.s.e.SvnKitEnvironmentRepository  : Repo already checked out - updating instead.
2017-02-07 14:44:35.108 DEBUG 28776 --- [nfoReplicator-0] o.s.c.c.s.e.SvnKitEnvironmentRepository  : Repo already checked out - updating instead.
2017-02-07 14:45:07.108 DEBUG 28776 --- [nfoReplicator-0] o.s.c.c.s.e.SvnKitEnvironmentRepository  : Repo already checked out - updating instead.
Sayantan
  • 564
  • 2
  • 7
  • 23
  • So, your question has nothing to do with svn, just getting it to register in discovery? – spencergibb Feb 07 '17 at 23:23
  • well it is about getting config server working with SVN, seems like with the above configuration it is repeatedly trying to update the local copy of the repo, not sure why, which probably is the reason why in Eureka the instance of the config server is shown as "DOWN", where I am going wrong? @spencergibb - I did see your answer to [here](http://stackoverflow.com/a/33979236/3950849), but I kept my config files under a specific branch and I referred that in the default-label configuration (also tried as part of the svn.url configuration without default-label), is that the problem? – Sayantan Feb 08 '17 at 04:45
  • just to make sure why there is no answer, my organization moved out of SVN to Git and we are now using native location support for config server – Sayantan Aug 08 '18 at 08:48

0 Answers0