views:

142

answers:

0

We have an application utilizing NHibernate 2.1.2, Npgsql 2.0.8 and PostgreSQL 8.3.7.

We notice that the connection-pool for our application gets trashed at regular time-intervals in our production-enviroment, not occasionally but every 5 hours.

When looking at the logfile for postgres, we see this:

2010-03-08 00:02:02 CET LOG:  incomplete startup packet
2010-03-08 05:02:01 CET LOG:  incomplete startup packet
2010-03-08 10:02:02 CET LOG:  incomplete startup packet
2010-03-08 15:02:02 CET LOG:  incomplete startup packet
2010-03-08 20:02:01 CET LOG:  incomplete startup packet
2010-03-09 00:02:01 CET LOG:  incomplete startup packet
2010-03-09 05:02:01 CET LOG:  incomplete startup packet
2010-03-09 10:02:02 CET LOG:  incomplete startup packet
2010-03-09 15:02:02 CET LOG:  incomplete startup packet
2010-03-09 20:02:01 CET LOG:  incomplete startup packet
2010-03-10 00:02:01 CET LOG:  incomplete startup packet
2010-03-10 05:02:01 CET LOG:  incomplete startup packet
2010-03-10 10:02:01 CET LOG:  incomplete startup packet

Where these timestamps corresponds to the errors we are getting in the application. Now, the weird thing is that we have several applications that connects to this database, meaning that it shouldn't be this periodically (at best, periodically per app). This leads me to believe that something is happening at server-level, either on the Windows 2008-server that act as webserver, or the Linux-based postgres-server.

I first thought it had someting to do with the firewalling in between them (we use connection-tracking for databaseconnections aswell), but I cant find anything that corresponds to that time-interval. I will try to bypass the connection-tracking just to rule out that option.

Has anyone noticed similar behaviour using the NHibernate/-Npgsql-stack?

EDIT: Seems like the application breaks because of maintenance-jobs are running when my app tries to reuse a connection from the pool, with not just a simple timeout but with a "Unknown response" instead. This might belong on serverfault.com, however it might be useful information for developers using Npgsql (since it's Npgsql that breaks).