Shalex:
Unfortunately, while the error is not occurring normally on my workstation, it is still happening on other machines. And we have devised a very simple test that can reliably reproduce the problem within a few minutes. And whatever the issue is, it has nothing to do with transactions or Entity Framework.
1. Set up a Unit Test with the following code:
Code: Select all
[TestCategory( "PubSubBufferPostrgres" ), TestMethod, Timeout( 600000 )]
public void TestPostgresPgSqlConnection() {
while ( true ) {
try {
using ( PgSqlConnection connection = new PgSqlConnection( "User Id=CarSystem;Password=ELSAGelsag;Host=localhost;Database=CarSystem;Schema=security" ) ) {
connection.Open();
}
} catch ( Exception e ) {
if ( e.Message != "Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host." &&
e.Message != "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host." &&
e.Message != "No connection could be made because the target machine actively refused it 127.0.0.1:5432" &&
e.Message != "the database system is starting up" &&
e.Message != "the database system is shutting down" &&
e.Message != "Transport channel is closed." )
Console.WriteLine( "Crash!" );
}
}
}
2. Place a breakpoint on the line that outputs "Crash!" to the console.
3. Start the unit test running.
4. Make sure the test is running long enough for a connection to be added to the connection pool. You can do this by waiting for a minute after the test begins. Note that the problem will not occur at this point, no matter how long you wait.
5. Here's the step that will cause the problem to happen. Go into Control Panel, Windows Services, and stop the Postgres server. Wait a few seconds and restart it.
6. Within 10 minutes of restarting the server, you should hit the breakpoint.
At this point, if you were to run the unit test continuously, you will continue to get the error. The error is not generated on each iteration of the loop. And you will note that there is nothing multithreaded about this test.
We are not saying that the cause of the problem is that the Postgres server is going down and restarting on its own. Note that we are trapping the errors that are generated when the server does go down in our system and we know that the it's not going down in the field. It's some sort of issue with faulty connections in the connection pool. We don't know what's going on inside of the server or your code. We do know that this method will reliably produce the error within a very short time.
We are aiming for a June 15 release, and we really need this issue to be resolved. Whatever is causing the problem happens regularly on the test machines we have in the field and is causing them to be extremely unreliable. We can't release with the software this unreliable.
Tony