System.Net.Http.HttpRequestException after connection is open for some time

I am trying to use this library on Azure Functions, and need to optimize total time to be small. So to optimize instantiation, I moved the Neo4jClient.GraphClient to the class and put it to be static.

But after some time after the function runs, when I call the function again, I am getting this:

System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: The connection was closed unexpectedly. at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar) --- End of inner exception stack trace --- at Neo4jClient.GraphClient.Neo4jClient.IRawGraphClient.ExecuteGetCypherResults[TResult](CypherQuery query) at Neo4jClient.Cypher.CypherFluentQuery``1.get_Results() at EasyTimeFunctionAppv1.Function1.<Graph>d__4.MoveNext()

I understand that the server closes the connection.

If I instantiate the Neo4jClient.GraphClient every time the function is called, total time is about 600ms, but if I put it on static and only open the connetion every time the function is called, total time drops to about 400ms .

Is it possible to have a Disconnect and DisconnectAsync methods, so I can close the connection after I do my Queries, but keep the Neo4jClient.GraphClient object ? Would it work well with multiple parallel instances of the same function being called at the same time?

[cskardon]

In a console app you can leave hours between calls and the connection won’t be terminated (example code below) - there’s nothing I can do if Azure actively kills the connections itself. There’s nothing to code around - all I could do would be to catch the exception and recreate an HttpClient (if that’s what it is) - and that’s not performant - and in my view - hides the problem.

As I said above - a Disconnect method would do nothing there is no active connection kept open. Connect simply instantiates an HttpClient and calls on the DB to get information (version etc) about it, it doesn’t then keep the connection open.

An HttpClient has a connection pool, and I’m guessing (and it is just a guess) that Azure Functions are killing those off - unfortunately I have no time to test with a plain HttpClient on an Azure Function to test it - if it is that then I would suggest maybe writing your own HttpClientWrapper that can kill/restart the client on demand - you can pass that in to the constructor and manage it that way. An example is in the code base.

It’s not something I would put into the client at the moment, if you do some more investigations with the HttpClient and find it is that, then by all means reopen this, add some ideas and then do a pull request, and we can take it from there.

//You can leave this for hours between pressing ENTER and it will not timeout.
using System;
using System.Linq;
using Neo4jClient;

internal class Program
{
    private static void Main(string[] args)
    {
        var f = new Function();
        f.GetCount();
        Console.WriteLine("type 'EXIT' to exit");
        var input = Console.ReadLine();

        while (input.ToLowerInvariant() != "exit")
        {
            f.GetCount();
                
            input = Console.ReadLine();
        }
    }
}

public class Function
{
    private static readonly IGraphClient Client;

    static Function()
    {
        Client = new GraphClient(new Uri("http://localhost.:7474/db/data"), "neo4j", "neo");
        Client.Connect();
    }

    public void GetCount()
    {
        var count = Client.Cypher.Match("(n)").Return(n => n.Count()).Results.Single();
        Console.WriteLine($"{DateTime.Now:yyyy-MM-dd HH:mm:ss} There are {count} nodes in the DB at the moment.");
    }
}

[TonyHenrique]

The issue is that GraphClient throws an Exception if connection is opened for some time, and there is no other way to control it and recover from this situation unless we create another GraphClient object.

The BoltGraphClient works flawlessy in all tests I made.

For the library improvement: This can be added on todo; check how to make GraphClient more stable / controllable on long shared static instantiation scenarios like the Azure Functions.

For my case I will use the BoltGraphClient . Problem solved for now.