What is the Best Practice for managing the GremlinClient object in C#? Is it better to create a SingleInstance (via Dependency Injection) or using Dispose on the object after each call or with a using
using (var client = new GremlinClient(...))
{
var results = client.SubmitAsync(query);
}
Since its a Sockets connection to the server, I assumed that reusing the client was the best practice, but I've been getting this error and I haven't been able to determine the root cause.
Unable to read data from the transport connection:
An existing connection was forcibly closed by the remote host.
The recommendation is to use just one GremlinClient object and to reuse that across your application because the client uses a connection pool so the same connection can be used again for different requests instead of having to create and tear down one connection for each request. The driver also supports request pipelining since version 3.4.0 which means that the same connection can be used for different requests in parallel which reduces the number of required connections. That can of course also only work if you reuse the client.
The problem you describe however could be caused by a bug in the Gremlin.Net driver. If you are using version 3.4.0 of Gremlin.Net, then it could be this bug that can lead to a huge number of created connections. In that case, you can avoid it by downgrading to a 3.3.5 until we release a fix with version 3.4.1. If you also see the problem in version 3.3.5, then please create an issue in TinkerPop's issue tracker to describe the problem.
There could of course also be another reason for the server to close the connection. That would need to be investigated in more depth to understand the reason, e.g., with a tool like Wireshark by inspecting the network traffic between the driver and Cosmos DB.
Related
I am not sure if this is the right place to ask this question. Please point out to me where if this is the case.
I must build a multi user, stateful (sessions; object persistance) web application that will uses .NET in the backend and must connect to R in order to perform calculations on data that lies in a SQL server 2016 DB. Basically, I need to connect a MS based backend with R.
Everything is clear, except for the problem that I need to find an R server that handles sessions. I know shiny but I can't use it (long story).
rApache and openCPU do not handle sessions.
Rserve for windows is very limited (no parallel connections are supported, subsequent connections share the same namespace and sessions are not supported - this is a consequence of the fact that parallel connections are not supported)
Finally, I have seen Rook (i.e. Run R/Rook as a web server on startup) but I can't read anywhere, even the docs. if it is able to deal with sessions. My question is: is there a non stateless R web server or does anyone knows if Rook is stateless?
EDIT:
Apparently, this question has been around for longer: http://jeffreyhorner.tumblr.com/about#comment-789093732
I'm having issues with SignalR failing to complete its connection cycle when running in a load balanced environment. I’m exploring Redis as a means of addressing this, but want a quick sanity check that I’m not overlooking something obvious.
Symptoms –
Looking at the network traffic, I can see the negotiate and connect requests made, via XHR and websockets respectively, which is what I’d expect. However, the start request fails with
Error occurred while subscribing to realtime feed. Error: Invalid start response: ''. Stopping the connection.
And an error message of ({"source":null,"context":{"readyState":4, "responseText":"","status":200, "statusText":"OK"}})
As expected, this occurs when the connect and start requests are made on different servers. Also, works 100% of the time in a non load-balanced environment.
Is this something that a Redis backplane will fix? It seems to make sense, but most of the rational I’ve seen for adding a backplane is around hub messaging getting lost, not failing to make a connection, so I'm wondering if I'm overlooking something basic.
Thanks!
I know this is a little late, but I believe that the backplane only allows one to send messages between the different environments user pools, it doesn't have any affect on how the connections are made or closed.
Yes, you are right. Backplane acts as cache to pass messages to other servers behind load balancer. Connection on load balancer is a different and a tricky topic, for which I am also looking for an answer
When using web services (we're specifically using asmx and WCF) with ASP.NET, what is the best way to establish a SQL connection? Right now, I'm establishing a new connection for each web service call, but I'm not convinced this will be too efficient when there will be thousands of users connecting. Any insight on this topic would be much appreciated.
What you are doing is fairly standard.
Assuming you are using the same connection string, the connections will be coming from the connection pool, which is the most efficient way to get connections already.
Only doing the work required and closing the connection on each call is good practice.
One thing you can do is cache results and return the cached results for calls that are not likely to result in changed data over the life of the cache item. This will reduce database calls.
It is strongly recommended that you always close the connection when you are finished using it so that the connection will be returned to the pool. You can do this using either the Close or Dispose methods of the Connection object, or by opening all connections inside a using statement in C#. Connections that are not explicitly closed might not be added or returned to the pool.
You should add "Pooling = true" (and add a non-zero "Min Pool Size") to the connection string.
Let the provider handle connection pooling for you; don't try to do better than it - you will fail.
With the default connection settings the provider will maintain a connection pool. When you close/dispose, the connection is actually just released to the pool. it is not necessarily really closed.
By default, SqlConnections make use of connection pooling, which will allow the system to manage the re-use of previous connection objects rather than truly creating "new" connections for each request - up to a pool maximum value. And its built-in, so you don't really have to do anything to leverage it.
Writing your own pooling/connection manager is fraught with peril, and leads to all manner of evil, so it seems to me allowing the system to manage your connections from the pool is probably your best bet.
I have heard the term connection pooling and looked for some references by googling it... But can't get the idea when to use it....
When should i consider using
connection pooling?
What are the advantages and
disadvantagesof connection pooling?
Any suggestion....
The idea is that you do not open and close a single connection to your database, instead you create a "pool" of open connections and then reuse them. Once a single thread or procedure is done, it puts the connection back into the pool and, so that it is available to other threads. The idea behind it is that typically you don't have more than some 50 parallel connections and that opening a connection is time- and resource- consuming.
When should i consider using
connection pooling?
Always for production system.
What are the advantages and
disadvantages of connection pooling?
Advantages:
Performance. Use a fixed pool of connection and avoid the costly creation and release of connections.
Shared infrastructure. If your database is shared between several apps, you don't want one app to exhaust all connections. Pooling help to limit the number of connection per app.
Licensing. Depending on your database license, the number of concurrent client is limited. You can set a pool with the number of authorized connections. If no connection is available, client waits until one is available, or times out.
Connectivity issue. The connection pool that is between the client and the database, can provide handy features such as "ping" test, connection retry, etc. transparently for the client. In worse case, there is a time-out.
Monitoring. You can monitor the pool, see the number of active connections, etc.
Disadvantage:
You need to set it up and configure it, which is really peanuts usually.
You should use connection pooling whenever the time to establish a connection is greater than zero (pretty much always) and when there is a sufficient average usage such that the connection is likely to be used again before it times out.
Advantages are it's much faster to open/close new connections as they're not really opened and closed, they're just checked out/in to a pool.
Disadvantage would be in some connection pools you'll get an error if all pooled connections are in use. This usually is a good thing as it indicates a problem with the calling code not closing connections, but if you legitimately need more connections than are in the pool and haven't configured it properly, you could get errors where you wouldn't otherwise.
And of course there will be other pros and cons depending on the specific environment you're working in and database.
In .NET, if you are using the same connection string for data access then you already have connection pooling. The concept is to reuse an idle connection without having to tear it down & recreate it, thereby saving server resources.
This is of-course taking into consideration that you are closing open connections upon completion of your work.
connection pooling enables re-use of an existing, but not used database connection. by using it you eliminate the overhead of the connection/disconnection to the database server. it provides a significant performance boost in most cases. the only reason i can think of not to use it is if your software won't be connecting frequently enough to keep the connections alive or if there's some bug in the pooling layer.
If we required to communicate with the database multiple times then it is not recommended to create a separate Connection Object every time, because creating and destroying connection object impacts performance.
To overcome this problem we should use a connection pool.
If we want to communicate with the database then we request a connection pool to provide a connection. Once we got the connection, by using it we can communicate with the database.
After completing our work, we can return the connection object back to the pool instead of destroying it.
The main advantage of connection pooling is to reuse the same connection object multiple times.
I've got a number of ASP.Net websites (.Net v3.5) running on a server with a SQL 2000 database backend. For several months, I've been receiving seemingly random InvalidOperationExceptions with the message "Internal connection fatal error". Sometimes there's a few days in between, while other times there are multiple errors per day.
The exception is not limited to one site in particular, though they share business and data access assemblies. The error seems to always be thrown from SqlClient.TdsParser.Run(). It sometimes is thrown from old-school direct SqlCommand.Execute() calls, while other times it is thrown from Linq2Sql code.
I've been assured by the network guys that there are no errors or packets lost on their end. Has anyone else experienced this? Could it be a driver problem? We have been unable as of yet to pinpoint a specific trigger for this exception.
We're running II6 on Windows Server 2003.
After a few months of ignoring this issue, it started to reach a critical mass as traffic gradually increased. Under heavy load, including some crawlers, things got crazy and these errors poured in nonstop.
Through trial and error, we eventually tracked down a handful of SqlCommand or LINQ queries whose SqlConnection wasn't closed immediately after use. Instead, through some sloppy programming originating from a misunderstanding of LINQ connections, the DataContext objects were disposed (and connections closed) only at the end of a request rather than immediately.
Once we refactored these methods to immediately close the connection with a C# "using" block (freeing up that pool for the next request), we received no more errors. While we still don't know the underlying reason that a connection pool would get so mixed up, we were able to cease all errors of this type. This problem was resolved in conjunction with another similar error I posted, found here: Why is my SqlCommand returning a string when it should be an int?
Sounds like the database connection is getting dropped or timing out.
We recently had similar issues moving to IIS 6 from IIS 5 connecting to SQL 2000. Our issue was solved by increasing number of ephemeral ports available.
Look at the usage of the ephemeral ports by the IIS server. The default max no. of ports available is normally 4000. You might want to consider increasing this if the sites on your server are particularly busy or your application is making a lot of database calls.
You can monitor these first to see if going over max limit.
Search Microsoft Knowledge base for "MaxUserPort" and "TcpTimedWaitDelay" and make necessary registry changes. Make sure you back up registry or snapshot server before making the changes. Will need to reboot for changes to take effect.
You should double check your database and recordset connection are being closed after use. Not closing will use up this port range unnecessarily.
Check the efficiency of your stored procedures anyway as they might be taking longer than they need too.
"If you rapidly open and close 4000 sockets in less than four minutes, you will reach the default maximum setting for client anonymous ports, and new socket connection attempts fail until the existing set of TIME_WAIT sockets times out." - from http://support.microsoft.com/kb/328476
Check your server's LOG folder (\program files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG or similar) for files named SqlDump*.mdmp and SqlDump*.txt. If you do find any you'll have to take it to Product Support.
I was creating a new EF Core project and was trying to create the database to an external Linux server instead of a Windows Server or local one. After hours of searching I found out that I am using MySQL instead of the Microsoft SQL server.
I found it weird that everyone was using 1433 instead of the usual 3306. So to fix my 'Internal connection fatal error' I had to set up a docker instance of SQL Server bound to its default port of 1433.
It literally was that simple. In the docker repo look for "microsoft-mssql-server" and run the image as described neatly in the description below. Everything works now and I am able to push my database from my EF Core project to an external server.