fix(jersey3): Fix issue: server will not reregister after peer server restarts

[ouaibsky]

When we got a 404, the payload does not contains a json that can be map into an InstanceInfo

more detail with reprductibe example at: spring-cloud/spring-cloud-netflix#4220 (comment)

It's fixing issue:

• JerseyEurekaHttpClient issue with 404 responses in Spring Boot 3.x #1515
• and the related issue at spring-cloud-eureka: eureka server will not reregister after peer server restarts spring-cloud/spring-cloud-netflix#4220

[ouaibsky]

Hello,
Can someone have a look please ?

[ouaibsky]

Hi @howardyuan
Can you have a look please ?

[ouaibsky]

Thx you @howardyuan
Could a maintainer take a look ? maybe @drobertduke ?

Thx in advance
Chris.

[RolandStaub]

@ouaibsky will this fix get merged soon, or are there other concerns ?

[ouaibsky]

@ouaibsky will this fix get merged soon, or are there other concerns ?

I would like this to be merged, but looks like there is no maintainer to validate or ask question.
This fix works like a charm where I deploied it with a custom distribution.

[ouaibsky]

Hi @paulbakker, I'm looking for a maintainer to review this PR.
Can you help me please ?
Thx
Ouaibsky

[ouaibsky]

Hi

@howardyuan or @OlgaMaciaszek , is it possible to merge please ?
Thx in advance

[OlgaMaciaszek]

Hi @ouaibsky, I'm not a maintainer of this repo - only of Spring Cloud Netflix, but @howardyuan should be able to help with this.

[LozinskiyIlya]

Currently, after a restart of the Eureka server, all registered clients attempt to renew their leases. However, this does not trigger automatic re-registration when the server comes back online. As a result, any deployment of the Eureka server forces us to redeploy each client peer manually to ensure re-registration.

It would be ideal if the Eureka client could handle this re-registration automatically without requiring a redeploy of each peer, ensuring that the clients can recover without needing to restart after a server restart.

[Subrhamanya]

@howardyuan any timeframe when we can expect the release with this fix?

[ph33rtehgd]

@howardyuan Any chance this can get merged and we can get a 2.0.6 release? A new release will also help us get #1601 released as well. This will help out for Spring Netflix to be able to proceed to with excluding commons-configuration (and by extension commons-lang), helping those of us battling the vulnerability issues brought by these old libraries.

[davidmalis]

@ouaibsky,

I ran into this issue while using the Hazelcast Eureka Discovery plugin, which uses the Jersey impl. of the client.

I see that you’ve been trying for a long time to get this PR merged, but it doesn’t seem to be happening. I’ll probably have to fork this repository to continue with my work.

Just a suggestion — I think the fix would be more complete if it were written like this:

if (response.getStatus() == Status.OK.getStatusCode() && response.hasEntity()) {
   eurekaResponseBuilder.entity(response.readEntity(InstanceInfo.class));
}

There are already examples in the same class showing how to handle the response body correctly.

Cheers!