Registering with Eureka discovery server working, but renew failing. about discovery HOT 10 CLOSED

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/161556905

The labels on this github issue will be updated when the story is started.

from discovery.

Hi @mries92

Are you running one of the Steeltoe samples, or a different app that is based on one of them?

It looks like the actual exception is missing from your stack trace there, could you include a bit more of the logs please?
If you are not running one of the Steeltoe samples, please share which versions of [ASP].NET [Core] and Steeltoe you're running?

from discovery.

What stack are you deploying the app to? (eg: windows2012R2, windows2016, cflinuxfs2, cflinuxfs3)
Can you confirm that DNS is working reliably in the cell you're deploying to?
Have you tried deploying one of the Steeltoe Discovery samples onto your infrastructure to make sure that it isn't an environmental issue?

No such device or address typically means either DNS has failed, or you've made a request to a bad server address. Considering that it can succeed, I don't think the address is likely to be bad. Does it successfully register every time your restart the app?
Configuring the log level for Steeltoe to Debug or Trace could provide some additional information.

from discovery.

Two more things to try, in addition to deploying the Steeltoe samples -

1. I pushed a new release of Discovery to the dev feed that logs the url when the request fails, so we can at least rule out any surprises there - the version is '2.2.0-dev-287'
2. Possibly a long shot, but opt out of the SocketsHttpHandler that shipped with .NET Core 2.1 might give us other ideas if the results change

from discovery.

Hey Tim,

Sorry for the late response. We are deploying on cflinuxfs2. I tried deploying the fortune teller samples a while back and was experiencing a similar issue, but I can try it again tomorrow. One thing I will mention, a suggestion you made to a colleague in another issue seems to have fixed my problem.

I added "AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);" to my main method in Program.cs, and now it is successfully registering (every time) and renewing consistently.

from discovery.

Hey Tim,

Just an update on the situation. Today I tried building and deploying the Fortune-Teller samples for circuit breaker again. I can confirm the exact same behavior we saw with our services. They sporadically succeed at registering with the Eureka server, but are dropped when the renew is attempted.

When adding the flag mentioned previously to the example services Program.cs, the register works successfully. However, this doesn't solve everything. Although the service registers successfully and it is listed in the Eureka management console, we are unable to hit the service by referencing it by name. We are still able to hit the java services by name however.

from discovery.

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/161733358

The labels on this github issue will be updated when the story is started.

from discovery.

we are unable to hit the service by referencing it by name - does that mean you're still seeing exceptions that appear to be DNS related, but only in .NET apps?

Its interesting that opting out of SocketsHttpHandler would resolve some, but no all instances of the issue

from discovery.

That is correct. Using the same Eureka instance for both .NET and Java apps, the Java apps are discoverable by name but the .NET ones are not. Interestingly, we can hit the Java services by name from the .NET services, but not vice-versa. So it seems the fetch registry is working on the .NET side, just not the actual registration (even though it says it registers successfully and appears in the management console).

As you mentioned, I find it strange that SocketsHttpHandler fixes some issues, and causes others. I have talked with our cloud team and they are not sure what is causing the problem. It seems like it may be unique to our instance of PCF, which might make this issue hard to track down.

Edit: And to answer for my colleague in the other thread. Yes, this issue is related to #47 .

from discovery.

Closing this issue. If this is still an issue please reopen under the steeltoe repository.

from discovery.