Frequent "Unable to sign the data" errors in multi-threaded SSL scenario

[rayrad]

Problem
Multiple asynchronous calls to query data from PostgreSQL server with SSL enabled yields Devart.Data.PostgreSql.PgSqlException with error code 08006 and message "Unable to sign the data."

In a test of about 30 DB calls, I consistently see 3-4 such errors. This is much more frequent than the once per 2 million in this post.

Some notes:

• With one thread the error does not occurr. With two or more it shows up sporadically.

• A new PgSqlConnection is constructed and disposed for each database call.

• Uniquely named .crt and .key files are created for each PgSqlConnection instance constructed (without this "File is already in use by another process" errors happen)

• Also tried using MemCryptStorage but it had other problems that indicated it may not be built for high concurrent usage. Plus it also got some of these "Unable to sign the data" errors.

• Since everything is as isolated as possible (unique cert files for each connection, unique connection for each DB call) I shouldn't be running up against dotConnect for PostgreSql not being thread-safe. Unless, of course, it is utilizing a shared (static?) resource in a non-thread safe manner.

• Since the majority of calls succeed, I presume my general configuration (SSL certs, connection str, etc.) is correct.

• Setting Pooling=false in the connection string yielded an exception with message "Transport channel is closed.'"

• Setting Validate Connection=true in the connection string did not reduce the number of of "Unable to sign the data" errors.

System Info:

• PostgreSQL Server: PostgreSQL 10.4 on 64-bit Linux

• This is a client's server, not our own, so I have no access to the host OS or hardware.

• Client application is netcoreapp 2.1 running on Windows 10

• Using Devart.Data.PostgreSql package version 7.12.1357

• Connection string:

  Code: Select all

  host=name.othername.net;user id=someuser;password=somepw;database=dbNamer;port=5432

Question
Do you have any ideas of things to try before I undertake the effort of packaging up an app to reproduce the problem?

Thank you very much in advance for any assistance.

Dave Parker

[Pinturiccio]

We have answered you via e-mail.