communicating between services results in "The operation timed out" error.

[fauxcoding]

I'm using the following Service Fabric Mesh example with no changes to the code.

https://github.com/Azure-Samples/service-fabric-mesh/tree/master/src/todolistapp

• Visual Studio 2017 - 15.7.5
• Microsoft Azure Service Fabric Mesh SDK (Preview) - 3.2.162

Running Locally

If I run the solution locally I get WinHttpException: The server name or address could not be resolved when trying to communicate with the ToDoService as it cannot resolve the address.

Here's the snippet that does the call...

public void OnGet()
{
    HttpClient client = new HttpClient();

    using (HttpResponseMessage response = client.GetAsync(backendUrl).GetAwaiter().GetResult())
    {
        if (response.StatusCode == System.Net.HttpStatusCode.OK)
        {
            Items = Newtonsoft.Json.JsonConvert.DeserializeObject<Model.ToDoItem[]>(response.Content.ReadAsStringAsync().Result);
        }
    }
}
private static string backendDNSName = $"{Environment.GetEnvironmentVariable("ServiceName")}";
private static Uri backendUrl = new Uri($"http://{backendDNSName}:{Environment.GetEnvironmentVariable("ApiHostPort")}/api/todo");

I've even tried changing the Url to be{serviceName}.{appName}when running locally and I still get the same exception.

In Azure If I publish the application to Azure I get a mixture of two different errors which I don't fully understand.

I deployed this the other day and got the following error...

webfrontend GET /api/todo
An error occurred while sending the request. The operation timed out

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter.GetResult (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Net.Http.DiagnosticsHandler+<SendAsync>d__2.MoveNext (System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
Inner exception System.Net.Http.WinHttpException handled at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw:
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Threading.Tasks.RendezvousAwaitable`1.GetResult (System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Net.Http.WinHttpHandler+<StartRequest>d__105.MoveNext (System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)

I published it today and got this error...

WinHttpException: The server name or address could not be resolved

[fauxcoding]

@ChackDan - Any idea what might be causing this?

My colleagues and I are currently trialling this service and none of us can seem to resolve DNS within the cluster.

We've been following the steps outlined in the documentation https://docs.microsoft.com/en-us/azure/service-fabric-mesh/service-fabric-mesh-tutorial-create-dotnetcore

Any help is greatly appreciated!

[fauxcoding]

The DNS is now resolving in Azure with no changes to the code. However, it still won't resolve locally (which isn't a massive issue for me at this moment in time)

I'm guessing that things are changing your side @ChackDan if the DNS now suddenly resolves?

[ChackDan]

Yes, We have improvements that we are making on the service at all times. We claim the features once they are stable and are also available on the SF SDK.

[tbertenshaw]

Are any of these SDK fixes for on prem dev clusters close? Or for beta testing? I assume these fixes will come in the sdk rather than the Visual studio tooling?

[ChackDan]

yes, some of these fixes are in the 6.3 CU1 release. The rest of them are in the next release 6.4 that is planned for Sept/2018.