spring-cloud-netflix: Eureka Server and Client incompatible between Angel (1.0.x) and Brixton (1.1.x)

After doing a fair bit of investigation with this I have found that the Eureka server and client components have some odd functionality between the two versions. This issue is mostly just for others running into this same problem during the upgrade path. If a solution can be found then that would be great, but there seems to be some documentation that is missing if this is what is going to happen going forward.

So there are 4 scenarios in total: (Angel.SR6 and Brixton.RC2 are the versions being used below)

1. Server (Brixton) and Client (Brixton)
2. Server (Brixton) and Client (Angel)
3. Server (Angel) and Client (Brixton)
4. Server (Angel) and Client (Angel)

Numbers 1 and 4 work as expected. However, numbers 2 and 3 have some differing results.

With 2, the client registers, but continues to register time after time. I found that this is because the instanceId doesn’t match what is stored in eureka server. With this setup, I don’t have access to the hostname via the configuration properties, so I can’t get the instanceId populated with the same value that eureka server contains without doing some code magic.

With 3, the client is able to register on the first lookup, but if the instance can’t be found in eureka server then it never is able to re-register and get back to the up state. One thing to note on this flavor as well is that I had to make the eureka.instance.metadata.instanceId property look exactly like the second half of the instanceId created dynamically by the org.springframework.cloud.commons.util.IdUtils class. So the resulting value ended up being: ${spring.application.name}:${server.port} in my test case and the instanceId field was ${spring.cloud.client.hostname}:${spring.application.name}:${server.port}. Upon digging further into this version of the issues I found that in the com.netflix.discovery.shared.transport.jersey.AbstractJerseyEurekaHttpClient#sendHeartBeat method that it was updated to see if the response had a body or not, since the response is a 404 the body doesn’t match what it’s expecting to get back and then throws a mapping exception. This path is what ends up causing the failure to re-register.