The Eureka client-server interactions are reasonably robust when you first start everything up (it doesn't matter what order the processes start), but once everything is running, if you kill Eureka and restart it then the apps do not re-register.

Comment From: spencergibb

It seems like I've seen this work :-(

Comment From: dsyer

Yeah me too, but not this week. Something changed.

Comment From: spencergibb

Basic authentication was added to samples eureka server, but I don't see where the username and password was added to client configuration except for the samples config server. I can't get the config server to decrypt it's password either btw.

Comment From: spencergibb

I added the authentication but I still get these errors even though the service registers with eureka:

java.lang.RuntimeException: Bad status: 405
    at com.netflix.discovery.DiscoveryClient.makeRemoteCall(DiscoveryClient.java:1001)
    at com.netflix.discovery.DiscoveryClient.makeRemoteCall(DiscoveryClient.java:909)
    at com.netflix.discovery.DiscoveryClient.access$300(DiscoveryClient.java:99)
    at com.netflix.discovery.DiscoveryClient$HeartbeatThread.run(DiscoveryClient.java:1405)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

2014-10-16 16:44:14.599 ERROR 90097 --- [scoveryClient-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_SAMPLEFRONTENDSERVICE/sgibb-mbp.local - was unable to send heartbeat!

java.lang.RuntimeException: Bad status: 405
    at com.netflix.discovery.DiscoveryClient.makeRemoteCall(DiscoveryClient.java:1001)
    at com.netflix.discovery.DiscoveryClient.makeRemoteCall(DiscoveryClient.java:909)
    at com.netflix.discovery.DiscoveryClient.access$300(DiscoveryClient.java:99)
    at com.netflix.discovery.DiscoveryClient$HeartbeatThread.run(DiscoveryClient.java:1405)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

Comment From: dsyer

That 405 looks like a duplicate of #27.

The config server password needs a key store password. Running in Cloud Foundry it should be set by the scripts. Locally you need to set the same environment variable or system property. I wanted to show as much best practice as possible and not put plaintext passwords in config files.

Given that we don't want the password in source code, I guess we can remove the security from the eureka server sample as a temporary workaround, and see if that fixes this issue at least.

Comment From: eroaespinosa

Same problem